|
Re: [OpenDaylight TSC] Switch project leader
Ryan Goulding <ryandgoulding@...>
PTL title comes with responsibilities in ODL beyond committer. I think it is important to preserve a sole point of contact for the PTL position; since that person votes for their representative project regarding releases/delays etc. This is just my $0.02 though. Regards, Ryan Goulding
On Wed, Oct 28, 2015 at 10:20 PM, Gao Kai <gaok12@...> wrote:
|
|
|
|
Re: [OpenDaylight TSC] Switch project leader
Jensen Zhang
George and TSC, After discussing, we reach the following agreement:
|
|
|
|
Re: [OpenDaylight TSC] Switch project leader
Gao Kai <gaok12@...>
Putting Jensen as the one and only
PTL is fine with me. After all
titles are just titles.
toggle quoted messageShow quoted text
Regards, Kai
On 29/10/15 02:53, George Zhao wrote:
|
|
|
|
Re: [OpenDaylight TSC] Switch project leader
George Zhao <George.Y.Zhao@...>
I am just curious, will one as PTL, the other as project contact work for you.
Having multiple PTLs for one project has no precedent, I just want to point this out, not necessarily against it.
From: tsc-bounces@... [mailto:tsc-bounces@...]
On Behalf Of tony
Sent: Wednesday, October 28, 2015 10:54 AM To: Colin Dixon Cc: tsc@...; alto-dev@... Subject: Re: [OpenDaylight TSC] Switch project leader
Yes, of course. Actually, it is him that comes up with the suggestion. Since he is not a committer, I start the voting for him.
Thanks, Tony
|
|
|
|
Re: [OpenDaylight TSC] Switch project leader
xinwang
Yes, of course. Actually, it is him that comes up with the suggestion. Since he is not a committer, I start the voting for him.
toggle quoted messageShow quoted text
Thanks, Tony
|
|
|
|
Re: [OpenDaylight TSC] Switch project leader
Colin Dixon <colin@...>
That all looks good. Out of curiosity, is Shu aware of this? --Colin
On Wed, Oct 28, 2015 at 12:37 AM, wangxin <xinwang2014@...> wrote:
|
|
|
|
Switch project leader
xinwang
Dear TSC,
We have carried out a public vote for switching project leader in ALTO project [1][2][3]. We, all committers, agree that we switch Jensen Zhang as co-lead instead of Shu. Thanks, Tony
|
|
|
|
Re: Switch project leader
Y. Richard Yang
＋1 I believe that we have the votes to make the changes. Thanks a lot! Richard
On Mon, Oct 26, 2015 at 2:40 PM, Wendy Roome <wendy@...> wrote: Also +1. -- ===================================== | Y. Richard Yang <yry@...> | | Professor of Computer Science | =====================================
|
|
|
|
Re: Switch project leader
Wendy Roome
Also +1.
toggle quoted messageShow quoted text
- Wendy Roome
On Oct 21, 2015, at 11:09, 13xinwang@... wrote:
|
|
|
|
Re: Switch project leader
Xiao SHI <xiao.shi@...>
+1 Best, Xiao
On Wed, Oct 21, 2015 at 10:25 PM, Y. Richard Yang <yry@...> wrote:
|
|
|
|
NetJSON and ALTO
Y. Richard Yang
It may make sense for some of us to take a look at NetJSON. Wendy gave a thorough response, and some of us may want to take a close look as well. Richard ---------- Forwarded message ---------- From: Wendy Roome <w.roome@...> Date: Mon, Sep 21, 2015 at 10:50 AM Subject: Re: NetJSON and ALTO To: alto@... Cc: hrogge@..., aaron@..., "Y. Richard Yang" <yry@...>, manet@..., nemesis@... Thanks for letting the ALTO group know about NetJSON. NetJSON is related to the proposed ALTO extensions to describe network topology. However, I think ALTO's needs are sufficiently different, and sufficiently simpler, that there is no advantage using NetJSON in ALTO. The proposed ALTO topology extensions give clients a very simple, abstract view of the network so that clients can determine how much the paths between endpoints overlap. E.g., suppose a client wants to do parallel backups to two different cloud servers. If the paths to servers A & B have many common elements, while the paths to servers A & C do not, the client would prefer to use A & C. ALTO could use the NetJSON NetworkGraph sub-schema to describe topology, but that is considerably more complicated than what we have proposed. For example, a NetworkGraph has nodes, links that connect nodes, and descriptions of routing protocols. The front-runner for describing topology in ALTO is to provide a list of abstract network elements involved in the path between two endpoint clusters. The elements can be nodes, links, or combinations of those. A NetJSON NetworkGraph is considerably more complicated, and much closer to the physical network. Also, ALTO clients are typically enduser applications with minimal knowledge of network internals. They want ALTO to hide the details and give them just what the need, and no more. So few ALTO clients would need the rest of NetJSON, and forcing them to learn it would just make it harder to use ALTO. Similarly, I doubt that NetJSON libraries would simplify ALTO clients; it would just mean a client has to learn how to turn off features the client will never use. - Wendy Roome >Date: Mon, 14 Sep 2015 10:05:31 +0000 >From: Rick Taylor <rick@...> >To: Henning Rogge <hrogge@...>, "L. Aaron Kaplan" > <aaron@...> >Cc: manet IETF <manet@...>, Nemesis Capoano <nemesis@...>, > "alto@..." <alto@...> >Subject: Re: [alto] [manet] Request for feedback > >Hi All, > >I'm a big fan of this kind of thing in principle, and I like the use of >JSON, but I worry there is some cross-over with the work that is >happening in the ALTO group (I have cc'd them), and some of the work in >with RESTCONF from the NETCONF people (I'm less up to speed with what >they are doing). > >Does anyone from the ALTO group have any opinions? > >Rick > >On 13/09/15 14:06, Henning Rogge wrote: >>Hi everyone... >> >>I was involved in the discussions about NetJSON, have done a NetJSON >>implementation for Olsrd2 and played a bit with it. >> >>I think this could be very useful for the MANET group... yes, we can >>do everything we can do with NetJSON with SNMP and the corresponding >>mibs... >> >>but of course it would take weeks to get something complicated right >>and it would be protocol specific. >> >>It took me a two days and a few hundred lines of Javascript (and a >>javascript graph API) to just build a live monitoring webpage for >>olsrd2 that updates through XMLRPC. It was fun to do. >> >> >>I think we should look into NetJSON, make sure with some suggestion it >>fits both reactive and proactive protocols and standardize it. >> >>Henning Rogge >> >>On Thu, Sep 10, 2015 at 3:55 PM, L. Aaron Kaplan <aaron@...> >>wrote: >>>Hi MANET WG, >>> >>> >>>We would like to draw your attention to an upcoming new document called >>>"netJSON" and ask for your feedback. >>> >>>TL;DR: go to https://urldefense.proofpoint.com/v2/url?u=http-3A__netjson.org&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=wEy0rT9mpMQ_IruaoYGTpIB8kw_AV0o2zR2fCZlKGjw&s=ESmMYTQ8nJeilLuKJIZ9mCwEROKN5mP9ZMCJp_-3KKA&e= >>> >>> >>> >>>Background: Henning and me are both in an EU FP7 project (called >>>CONFINE). This gives us some financial means to focus on some projects. >>>One of these projects is what I usually call a "common node DB". The >>>idea being that every (community) wireless (mesh) network loves to >>>invent its own registry (LIR) database. There nodes and different >>>devices and their ownership are documented . Also on how to reach the >>>other owner. In essence, it's a necessity for us to have such a thing >>>for maintaining IP address assignments. >>>Often these node DBs don't end with IP address assignment >>>functionalities: they often include interesting network link planning >>>features, line of sight calculations, firmware config generation tools >>>and of course a lot of monitoring tools. >>> >>> >>>Right now the situation is that every (community) network loves to >>>invent its own node DB. So there is no standard. Hence we came together >>>and started to define a **simple** JSON based format for describing our >>>networks. This shall not replace SNMP nor netconf. It's a simple (as >>>opposed to *S*nmp) format definition. Very flexible, and people >>>essentially can opt in to what parts of it they want to support. >>> >>>Please note that this has a different focus than netconf. Also, it is >>>not SNMP. We looked at those. >>> >>>The focus of that format is to describe mesh networks. Wireless >>>(containing wired links for sure) mesh networks. >>> >>> >>>We also made a first RFC-ish draft: https://urldefense.proofpoint.com/v2/url?u=http-3A__netjson.org_rfc.html&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=wEy0rT9mpMQ_IruaoYGTpIB8kw_AV0o2zR2fCZlKGjw&s=B0PwEB-l47qftiSQYAqASXiFGxSzdoEq_5jWAAAQ7Ro&e= >>> >>> >>>The source code can be seen here: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_interop-2Ddev_netjson&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=wEy0rT9mpMQ_IruaoYGTpIB8kw_AV0o2zR2fCZlKGjw&s=84Uzj0bAUlE2ruXD0YGckt06iRJZ141u245eSnKyu9c&e= >>>(feel free to send pull requests via github) >>> >>>Ultimately, the goal will be to have interoperable mesh network >>>descriptions and thus being able to separate the coding work amongst >>>different (community) networks (or other players in this field). >>> >>> >>>Let us know, what you think. Thanks! >>>Aaron. >>> >>> >>> >>>_______________________________________________ >>>manet mailing list >>>manet@... >>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_manet&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=wEy0rT9mpMQ_IruaoYGTpIB8kw_AV0o2zR2fCZlKGjw&s=6jNncRndzz3mkpHIg3vLQCA15Or0BfC7mmKGAKwL4G4&e= >>> >> >>_______________________________________________ >>manet mailing list >>manet@... >>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_manet&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=wEy0rT9mpMQ_IruaoYGTpIB8kw_AV0o2zR2fCZlKGjw&s=6jNncRndzz3mkpHIg3vLQCA15Or0BfC7mmKGAKwL4G4&e= >> > -- ===================================== | Y. Richard Yang <yry@...> | | Professor of Computer Science | =====================================
|
|
|
|
Re: Switch project leader
Y. Richard Yang
On Wednesday, October 21, 2015, <13xinwang@...> wrote: Dear all committers, +1 Richard
-- Richard
|
|
|
|
Switch project leader
xin wang
Dear all committers,
Since Shu got a high work load recently and he is not able to focus on ALTO project. I'd like to propose that we switch Jensen Zhang to be a co-lead of ALTO project. Jensen has been being involved in the project actively since ALTO Lithium release [1] and he will for sure contribute more in the future. Please vote +1, 0, -1 for the proposal. Thanks. [1] https://git.opendaylight.org/gerrit/#/q/project:alto+owner:jensenzhang. Thanks again, Tony
|
|
|
|
Re: Propose Jensen to be co-lead of ALTO
Gao Kai
Thanks Tony, it will
be very helpful!
toggle quoted messageShow quoted text
On 21/10/15 22:48, tony wrote:
Hi Kai and Shu,
|
|
|
|
Re: Propose Jensen to be co-lead of ALTO
xinwang
Hi Kai and Shu,
toggle quoted messageShow quoted text
I think I can start the vote to make Jensen a co-leader. And to get a clean record of email voting procedure, I will send a new voting email to all committers and cc to alto-dev. Thanks, Xin
|
|
|
|
Re: Propose Jensen to be co-lead of ALTO
Gao Kai
Shu, It’s nice to hear from you and I support the idea of making Jensen a co-leader. However, there are some procedures I’d like to point out: First according to this, this and this, only the commiters can vote for committer nominations and project leader election. According to Collin, a member of ODL TSC, there are only 4 committers and since there was no voting (as far as I know) you and I are not legal project leaders at the moment. It would be great if someone can continue to push forward the process of committer nominations and also this co-lead election. One major issue is that we must get at least 3 votes from the four committers, especially from Shi and Wendy. Regards, On 21/10/15 21:26, Shu Dong wrote:
|
|
|
|
Propose Jensen to be co-lead of ALTO
dongshu
Dear all, I got a high work load recently and am not able to focus on ALTO project. Hence, I'd like to propose Jensen Zhang to be a co-lead of ALTO project. Jensen has been being involved in the project actively since ALTO Lithium release [1] and he will for sure contribute more in the future. Please vote +1, 0, -1 for the proposal. Thanks. Best Regards, Shu
|
|
|
|
Re: alto pids
Y. Richard Yang
Some revisions... Please see below.
On Tuesday, October 20, 2015, Y. Richard Yang <yry@...> wrote:
Seeding with fixed switches may not be flexible. For example, what if you want a new switch to be an anchor. An alternative us to provide tags to switches. For example, the nearest-anchor call only defines the network map name and the names of pids. We have an API to allow assign tags to switch: sw1 -> netmap1:pid2, netmap3:pid10 In a sense we provide a map management API, which allows create maps, defines the grouping algorithm (e.g., nearest-anchor), and tag switches, ... Note that link based partition can be interesting as well. Richard
-- Richard
|
|
|
|
Re: alto pids
Y. Richard Yang
I made some changes to make the nearest-anchor more general. Please see below. On Tue, Oct 20, 2015 at 1:10 PM, Y. Richard Yang <yry@...> wrote:
"anchors": [ "pid1": ["sw1", "sw2"] , "pid2" : ["sw3"], "pid3": ["sw4", "sw5"] ], Hence each PID is seeded with a set, instead of a single switch. We can then approximate other design, for example using regular expressions. Richard
-- ===================================== | Y. Richard Yang <yry@...> | | Professor of Computer Science | =====================================
|
|
|
|
Re: alto pids
Y. Richard Yang
Good discussions. I have reported it as a bug in https://github.com/snlab/alto. In addition to reporting as a bug, which helps us to get priority, let's start some specific discussions. What we need is a mechanism so that an admin can define the partition of hosts into PIDs. Let me give a try to start a strawman. We can consider the hosts in the network as leaves in a graph. Each host also has a set of attributes (e.g., geolocation) beyond the graph properties. Hence, I assume that we need a mechanism to use these properties to group the hosts. A first idea coming to mind is cluster analysis (https://en.wikipedia.org/wiki/Cluster_analysis). Let me start with an anchor based approach. Assume that we allow the admin to define a set of anchors, where each anchor is a switch. { "netmap-grouping-alg": "nearest-anchor", "alg-metric": "hopcount", // it could be "nearest geo-location", if we know "anchors": [ "sw1", sw3", "sw4"], "cost-map-cal-alg": "avg" // cost from pid1 (sw1 cluster) to pid2 (sw2 cluster) is the average of host pairs } Then we can see that it defines three PIDs, where each PID is defined by an anchor in anchors. When an host is added, we can automatically compute which anchor is the nearest and hence assign it to it. We can prove that each PID is a connected component, if we assume the full graph is connected, when we consider graph hopcount. How to define a more general mechanism? Richard
On Tue, Oct 20, 2015 at 12:51 PM, Gao Kai <gaok12@...> wrote:
-- ===================================== | Y. Richard Yang <yry@...> | | Professor of Computer Science | =====================================
|
|
|