On Sep 30, 2015, at 8:34 PM, Y. Richard Yang <yang.r.yang@...> wrote:

Hi Azher,

It was great to you yesterday.

I cc'd the alto-team.

Jensen/Junzhuo/Tony: Azher from CalTech mentioned that an issue they are facing is that ODL l2switch (HostTracker) made one host appears at multiple locations. Our version does not have this problem, I believe. Could you please engage Azher to solve this problem?

Thanks a lot!

Richard

On Wednesday, September 30, 2015, Azher Mughal <azher@...> wrote:

Hi Richard,

Nice talking with you yesterday. Do yo mind sharing the project with us, so I can download and try it out. Current issues as I mentioned are hosts seen connected to various nodes which creates a total confusion.

Thanks
-Azher

--
Richard

--
You received this message because you are subscribed to the Google Groups "alto-design" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alto-design+unsubscribe@....
To post to this group, send email to alto-design@....
To view this discussion on the web visit https://groups.google.com/d/msgid/alto-design/CANUuoLo%2B30hrds%2BNWcJDO3yYtb7uN23yeEsPN6L4aUk%3DOuS55A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Hi Richard,

Nice talking with you yesterday. Do yo mind sharing the project with us, so I can download and try it out. Current issues as I mentioned are hosts seen connected to various nodes which creates a total confusion.

Thanks
-Azher

Yeah, I have created a branch based on 'stable/lithium' to implement sse in our ODL/ALTO server. And I will update it this week. But it is just a repo in our local server. Shall we make it public? (upload it to github? Since I cannot merge it to gerrit directly.)

Jensen

2015-09-29 23:44 GMT+08:00 Y. Richard Yang <yry@...>:

Wendy has already implemented this draft in her server. It will be great if we can do the same soon.

Richard

---------- Forwarded message ----------
From: Wendy Roome <w.roome@...>
Date: Tuesday, September 29, 2015
Subject: [alto] New Incremental Update draft
To: "alto@..." <alto@...>


Folks,

Richard & I updated the incremental update draft:

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dietf-2Dalto-2Dincr-2Dupdate-2Dsse-2D01.txt&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=DOFJXxQJVz_ERNgTqwtat30JEEXyPxEyMPYBPvV8rqY&s=slfp3TRkN394bivOqmD24pjhcrOGj7qyTMNTJYVSBIQ&e=


The primary change was I added a mechanism to let a client tell the server
to close the stream. This shuts the stream down quickly & cleanly. The
client can just close the stream, of course, but that can take a while for
the server to detect, and it looks like an I/O error.

Section 3 summarizes the other changes, most of which are clarifications.

The Alcatel-Lucent public server,
https://urldefense.proofpoint.com/v2/url?u=http-3A__alto.alcatel-2Dlucent.com-3A8000_directory&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=DOFJXxQJVz_ERNgTqwtat30JEEXyPxEyMPYBPvV8rqY&s=TWWzEEQgxCMd17ICx7chi8-DKni-0kcxNL1SVxaxFAo&e= , provides an Update Stream
resource as described in the -01 draft. The server updates the default
network map every 60 minutes (approximately), and every 5 minutes it
updates a few routingcost values for the default network map and a few
property values.

Note that because that server handles the interop test network, the
updates just replace the current values with the same values. But that
counts as an update in my server, so it exercises all of the update
plumbing.

One wart: when you create a new Update Stream, the initial response is
delayed for 50 seconds. I don't know what causes that delay, but it only
happens on this particular server, and it is very repeatable. That server
is in our corporate DMZ, so it may be a result of the firewall, or
routing, or some other security feature. In any case, once you get over
the initial 50 second delay, subsequent updates arrive quickly.

Oh yes, I could not find an SSE library, so I had to write my own. I would
greatly appreciate it if other people could try it and verify that my SSE
implementation meets the specification.

        - Wendy Roome



_______________________________________________
alto mailing list
alto@...
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=DOFJXxQJVz_ERNgTqwtat30JEEXyPxEyMPYBPvV8rqY&s=wi48BWjWERAAmlsmH5X4thluWqXWCcHVPBQOAk5lL_I&e=

--
Richard

--
You received this message because you are subscribed to the Google Groups "alto-design" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alto-design+unsubscribe@....
To post to this group, send email to alto-design@....
To view this discussion on the web visit https://groups.google.com/d/msgid/alto-design/CANUuoLpx_x6FUKQT-LTJ4pj96160GzWcFxMqgzeEWa64eEYBgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Wendy has already implemented this draft in her server. It will be great if we can do the same soon.

Richard

---------- Forwarded message ----------
From: Wendy Roome <w.roome@...>
Date: Tuesday, September 29, 2015
Subject: [alto] New Incremental Update draft
To: "alto@..." <alto@...>


Folks,

Richard & I updated the incremental update draft:

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dietf-2Dalto-2Dincr-2Dupdate-2Dsse-2D01.txt&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=DOFJXxQJVz_ERNgTqwtat30JEEXyPxEyMPYBPvV8rqY&s=slfp3TRkN394bivOqmD24pjhcrOGj7qyTMNTJYVSBIQ&e=


The primary change was I added a mechanism to let a client tell the server
to close the stream. This shuts the stream down quickly & cleanly. The
client can just close the stream, of course, but that can take a while for
the server to detect, and it looks like an I/O error.

Section 3 summarizes the other changes, most of which are clarifications.

The Alcatel-Lucent public server,
https://urldefense.proofpoint.com/v2/url?u=http-3A__alto.alcatel-2Dlucent.com-3A8000_directory&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=DOFJXxQJVz_ERNgTqwtat30JEEXyPxEyMPYBPvV8rqY&s=TWWzEEQgxCMd17ICx7chi8-DKni-0kcxNL1SVxaxFAo&e= , provides an Update Stream
resource as described in the -01 draft. The server updates the default
network map every 60 minutes (approximately), and every 5 minutes it
updates a few routingcost values for the default network map and a few
property values.

Note that because that server handles the interop test network, the
updates just replace the current values with the same values. But that
counts as an update in my server, so it exercises all of the update
plumbing.

One wart: when you create a new Update Stream, the initial response is
delayed for 50 seconds. I don't know what causes that delay, but it only
happens on this particular server, and it is very repeatable. That server
is in our corporate DMZ, so it may be a result of the firewall, or
routing, or some other security feature. In any case, once you get over
the initial 50 second delay, subsequent updates arrive quickly.

Oh yes, I could not find an SSE library, so I had to write my own. I would
greatly appreciate it if other people could try it and verify that my SSE
implementation meets the specification.

        - Wendy Roome



_______________________________________________
alto mailing list
alto@...
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=DOFJXxQJVz_ERNgTqwtat30JEEXyPxEyMPYBPvV8rqY&s=wi48BWjWERAAmlsmH5X4thluWqXWCcHVPBQOAk5lL_I&e=

--
Richard

--
You received this message because you are subscribed to the Google Groups "alto-design" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alto-design+unsubscribe@....
To post to this group, send email to alto-design@....
To view this discussion on the web visit https://groups.google.com/d/msgid/alto-design/CANUuoLpx_x6FUKQT-LTJ4pj96160GzWcFxMqgzeEWa64eEYBgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

On Sep 28, 2015, at 2:21 AM, Amit Mandke (ammandke) <ammandke@...> wrote:

That sounds great. 

It is hard to follow code change in different repository. Please submit your patches to ODL repo. I would recommend incremental smaller(working) patches than one big change if possible.

Thanks,

-Amit

From: Junzhuo Wang <wangjunzhuo200@...>
Date: Saturday, September 26, 2015 at 2:14 AM
To: Amit Mandke <ammandke@...>
Cc: "Y. Richard Yang" <yry@...>, 陈明明 <mingmingminne@...>, Evan Zeller <evanrzeller@...>, André Martins <aanm90@...>, "Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIES at Cisco)" <ttkacik@...>, "l2switch-dev@..." <l2switch-dev@...>, Shu Dong <dongs2011@...>, "linxiao9292@..." <linxiao9292@...>, Jensen Zhang <jingxuan.n.zhang@...>, "gaok12@..." <gaok12@...>, "alto-dev@..." <alto-dev@...>, Andreas Voellmy <andreas.voellmy@...>, Shigang Zhu <szhu@...>
Subject: Re: How to compute the routing path between two hosts in OpenDayLight?

Hi l2switch team,

I have changed the l2switch to construct flow entries to build shortest path between hosts and also provide the routing information to other modules. I'm very happy to submit my code and I have pushed my modified l2switch on github here: https://github.com/cs512/l2switch.

The current problem is that my modify is dummy so I need review. If any of you willing to do so, please contact me.

Regards,

Junzhuo

2015-08-10 1:57 GMT+08:00 Amit Mandke (ammandke) <ammandke@...>:

Richard and Junzhuo,

I would highly encourage you to submit your enhancements to l2switch. Please start contributing the project. Submit your proposal for Beryllium release.  

-Amit

From: <yang.r.yang@...> on behalf of "Y. Richard Yang" <yry@...>
Date: Sunday, August 9, 2015 at 7:01 AM
To: Junzhuo Wang <wangjunzhuo200@...>
Cc: 陈明明 <mingmingminne@...>, Amit Mandke <ammandke@...>, Evan Zeller <evanrzeller@...>, André Martins <aanm90@...>, "Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIES at Cisco)" <ttkacik@...>, "l2switch-dev@..." <l2switch-dev@...>, Shu Dong <dongs2011@...>, "linxiao9292@..." <linxiao9292@...>, Jensen Zhang <jingxuan.n.zhang@...>, "gaok12@..." <gaok12@...>, "alto-dev@..." <alto-dev@...>, Andreas Voellmy <andreas.voellmy@...>, Shigang Zhu <szhu@...>
Subject: Re: How to compute the routing path between two hosts in OpenDayLight?

To add a bit, according to my understanding:

- current l2switch uses flooding based on a single, shared spanning. Hence, assume a switch with k neighbors in the spanning tree, it needs only k rules in its flow table: for each incoming neighbor, flood to the other k-1 neighbors. If we use the number of links traversed as cost when computing ECS, this routing scheme is not useful, because the cost for each arc-dst pair is the same. 

- As a first step, we develop l2switch-plus, which adds higher priority flow rules: for a given src, dst MAC pairs, we find the unicast path from the tree, and add <src-Mac, dst-Mac> entries to the flow tables. Note that this may cause flow table explosion, which we can look into:

* We identify compression. 

* Another idea is that when computing ECS, we do not insert the Mac rules. They are triggered by packet-in only. 

* Yet another idea is that ECS will insert the rules but with a relatively short timeout. Hence those rules not used by app will timeout quickly.

- In the next step, we use the ip-mac binding table to convert an l2 path to an l3 path.

In the long run, the preceding is not complete. For example, what if GBP reroutes a flow through middle boxes. The preceding derivation based on l2switch routing is not correct. We need to look into the composition approach of ODL.

Richard

On Sunday, August 9, 2015, Junzhuo Wang <wangjunzhuo200@...> wrote:

Hi Mingming,

The current status is that Dijkstra algorithm is not be used in l2switch. The related code are all been annotated. And the authors of l2switch also says this module is not complete. Instead, it use STP to forward all packets to every devices in the network. So we decide to develop our own module “l2switch-plus” to enhance the ability of l2switch. As a result, we can get routing information easily.

Best regards,

Junzhuo

Hi all,

I am sorry to come back so late. I sent email to cisco's stuff last Tuesday. He replied me as below:

"

Hi Mingming,
I am sure there is somewhere used the Dijkstra algorithm for this. I guess l2switch is the project involving this. You can check their wiki and eventually drop a question to their mailing list. Also you can read the topology and compute by yourself.


Regards,
"

I don't know how it goes now(I missed sync up on Saturday). I will try to find Dijkstra algorithm in ODL. And keep on asking for help from the helper? Or it has already resolved. I should do sth else? Thank you!

Best regards,

Mingming

在 2015-08-08 10:00:35，"Y. Richard Yang" <yry@...> 写道：

On Fri, Aug 7, 2015 at 8:16 PM, Amit Mandke (ammandke) <ammandke@...> wrote:

addMacToMac is not complete. Some more implementation is required to make it work. Never got a time to fix it. All contributions are welcome.

To clarify,  it is incomplete because it handles only the case of the same-switch, as implied by Junzhuo's testing? So the contribution is to handle cross-switch routing?

Thanks.

Richard

From: Junzhuo Wang <wangjunzhuo200@...>
Date: Friday, August 7, 2015 at 8:24 AM
To: Evan Zeller <evanrzeller@...>
Cc: André Martins <aanm90@...>, "Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIES at Cisco)" <ttkacik@...>, "l2switch-dev@..." <l2switch-dev@...>, Amit Mandke <ammandke@...>, Shu Dong <dongs2011@...>, "linxiao9292@..." <linxiao9292@...>, Jensen Zhang <jingxuan.n.zhang@...>, 陈明明 <mingmingminne@...>, "Y. Richard Yang" <yry@...>, "gaok12@..." <gaok12@...>
Subject: Re: [L2switch-dev] How to compute the routing path between two hosts in OpenDayLight?

A further question. Is there a layer 3 routing module could make OpenFlow switcher acts like a traditional router?

Thanks!

Junzhuo

Hi Evan,

It great to have your reply! I’ve seen that the method “addBidirectionalMacToMacFlows” calls “addMacToMacFlow” twice. Based on the code, I assume in this implementation, the STP eliminate loops so all packets can be forwarded to all switchers. So only two flow entries could build a path between two MAC addresses.

But in my test, the MAC to MAC flow only be built when two hosts connected to the same switcher. This phenomenon really confuses me. I’m looking forward to your reply.

Thanks!

Junzhuo

The Minimum Spanning Tree is calculated to prevent loops in the network, those links that receive STP blocking status won't have flows written on them. FlowWriterServiceImpl.java in l2switch-main may have what you're looking for, it can create mac to mac flows, I'm not sure how robust the functionality is at the moment. 

On Thu, Aug 6, 2015 at 9:14 AM, Junzhuo Wang <wangjunzhuo200@...> wrote:

Hi André,

Thanks a lot for your reply! I’ve read the code from (https://github.com/opendaylight/l2switch/blob/master/loopremover/implementation/src/main/java/org/opendaylight/l2switch/loopremover/topology/NetworkGraphImpl.java#L123). The "getPath" method doesn’t exist anymore as you said. Also I did some tests and I found that the packets not always go through the shortest path. So I believe STP may be used as the current routing algorithm. If so, I can calculate the path by my self although it’s not a clean implementation. Let’s say what the code’s author says.

Junzhuo

Hi Junzhuo.
The code is here https://github.com/opendaylight/l2switch/tree/master/loopremover/implementation/src/main/java/org/opendaylight/l2switch/loopremover/topology
but I don't know if the service is working because of https://github.com/opendaylight/l2switch/blob/master/loopremover/implementation/src/main/java/org/opendaylight/l2switch/loopremover/topology/NetworkGraphService.java#L41
But I've send this email to the code's author to see what he says about it.
Best regards,
--André

On 06-08-2015 07:43, Junzhuo Wang wrote:

Hi all,

I’m a member from ODL/ALTO. I’m trying to find a API to compute the routing path between two hosts. So I read the code from openflowplugin, controller. It seems openflowplugin just set the flow table to switchers. And controller seems no longer handle the routing calculation now

 (org.opendaylight.controller.sal.routing doesn’t exist now).

Finally I found this page(https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:L2_Switch) saids that the l2switch now provide routing service. Which module should I use and how to get the route between two hosts by existing APIs?

Thanks,

Junzhuo

_______________________________________________
L2switch-dev mailing list
L2switch-dev@...https://lists.opendaylight.org/mailman/listinfo/l2switch-dev

--
Richard

That sounds great. 

It is hard to follow code change in different repository. Please submit your patches to ODL repo. I would recommend incremental smaller(working) patches than one big change if possible.

Thanks,

-Amit

From: Junzhuo Wang <wangjunzhuo200@...>
Date: Saturday, September 26, 2015 at 2:14 AM
To: Amit Mandke <ammandke@...>
Cc: "Y. Richard Yang" <yry@...>, 陈明明 <mingmingminne@...>, Evan Zeller <evanrzeller@...>, André Martins <aanm90@...>, "Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIES at Cisco)" <ttkacik@...>, "l2switch-dev@..." <l2switch-dev@...>, Shu Dong <dongs2011@...>, "linxiao9292@..." <linxiao9292@...>, Jensen Zhang <jingxuan.n.zhang@...>, "gaok12@..." <gaok12@...>, "alto-dev@..." <alto-dev@...>, Andreas Voellmy <andreas.voellmy@...>, Shigang Zhu <szhu@...>

Subject: Re: How to compute the routing path between two hosts in OpenDayLight?

Hi l2switch team,

I have changed the l2switch to construct flow entries to build shortest path between hosts and also provide the routing information to other modules. I'm very happy to submit my code and I have pushed my modified l2switch on github here: https://github.com/cs512/l2switch.

The current problem is that my modify is dummy so I need review. If any of you willing to do so, please contact me.

Regards,

Junzhuo

2015-08-10 1:57 GMT+08:00 Amit Mandke (ammandke) <ammandke@...>:

Richard and Junzhuo,

I would highly encourage you to submit your enhancements to l2switch. Please start contributing the project. Submit your proposal for Beryllium release.  

-Amit

From: <yang.r.yang@...> on behalf of "Y. Richard Yang" <yry@...>
Date: Sunday, August 9, 2015 at 7:01 AM
To: Junzhuo Wang <wangjunzhuo200@...>
Cc: 陈明明 <mingmingminne@...>, Amit Mandke <ammandke@...>, Evan Zeller <evanrzeller@...>, André Martins <aanm90@...>, "Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIES at Cisco)" <ttkacik@...>, "l2switch-dev@..." <l2switch-dev@...>, Shu Dong <dongs2011@...>, "linxiao9292@..." <linxiao9292@...>, Jensen Zhang <jingxuan.n.zhang@...>, "gaok12@..." <gaok12@...>, "alto-dev@..." <alto-dev@...>, Andreas Voellmy <andreas.voellmy@...>, Shigang Zhu <szhu@...>
Subject: Re: How to compute the routing path between two hosts in OpenDayLight?

To add a bit, according to my understanding:

- current l2switch uses flooding based on a single, shared spanning. Hence, assume a switch with k neighbors in the spanning tree, it needs only k rules in its flow table: for each incoming neighbor, flood to the other k-1 neighbors. If we use the number of links traversed as cost when computing ECS, this routing scheme is not useful, because the cost for each arc-dst pair is the same. 

- As a first step, we develop l2switch-plus, which adds higher priority flow rules: for a given src, dst MAC pairs, we find the unicast path from the tree, and add <src-Mac, dst-Mac> entries to the flow tables. Note that this may cause flow table explosion, which we can look into:

* We identify compression. 

* Another idea is that when computing ECS, we do not insert the Mac rules. They are triggered by packet-in only. 

* Yet another idea is that ECS will insert the rules but with a relatively short timeout. Hence those rules not used by app will timeout quickly.

- In the next step, we use the ip-mac binding table to convert an l2 path to an l3 path.

In the long run, the preceding is not complete. For example, what if GBP reroutes a flow through middle boxes. The preceding derivation based on l2switch routing is not correct. We need to look into the composition approach of ODL.

Richard

On Sunday, August 9, 2015, Junzhuo Wang <wangjunzhuo200@...> wrote:

Hi Mingming,

The current status is that Dijkstra algorithm is not be used in l2switch. The related code are all been annotated. And the authors of l2switch also says this module is not complete. Instead, it use STP to forward all packets to every devices in the network. So we decide to develop our own module “l2switch-plus” to enhance the ability of l2switch. As a result, we can get routing information easily.

Best regards,

Junzhuo

Hi all,

I am sorry to come back so late. I sent email to cisco's stuff last Tuesday. He replied me as below:

"

Hi Mingming,
I am sure there is somewhere used the Dijkstra algorithm for this. I guess l2switch is the project involving this. You can check their wiki and eventually drop a question to their mailing list. Also you can read the topology and compute by yourself.


Regards,
"

I don't know how it goes now(I missed sync up on Saturday). I will try to find Dijkstra algorithm in ODL. And keep on asking for help from the helper? Or it has already resolved. I should do sth else? Thank you!

Best regards,

Mingming

在 2015-08-08 10:00:35，"Y. Richard Yang" <yry@...> 写道：

On Fri, Aug 7, 2015 at 8:16 PM, Amit Mandke (ammandke) <ammandke@...> wrote:

addMacToMac is not complete. Some more implementation is required to make it work. Never got a time to fix it. All contributions are welcome.

To clarify,  it is incomplete because it handles only the case of the same-switch, as implied by Junzhuo's testing? So the contribution is to handle cross-switch routing?

Thanks.

Richard

From: Junzhuo Wang <wangjunzhuo200@...>
Date: Friday, August 7, 2015 at 8:24 AM
To: Evan Zeller <evanrzeller@...>
Cc: André Martins <aanm90@...>, "Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIES at Cisco)" <ttkacik@...>, "l2switch-dev@..." <l2switch-dev@...>, Amit Mandke <ammandke@...>, Shu Dong <dongs2011@...>, "linxiao9292@..." <linxiao9292@...>, Jensen Zhang <jingxuan.n.zhang@...>, 陈明明 <mingmingminne@...>, "Y. Richard Yang" <yry@...>, "gaok12@..." <gaok12@...>
Subject: Re: [L2switch-dev] How to compute the routing path between two hosts in OpenDayLight?

A further question. Is there a layer 3 routing module could make OpenFlow switcher acts like a traditional router?

Thanks!

Junzhuo

Hi Evan,

It great to have your reply! I’ve seen that the method “addBidirectionalMacToMacFlows” calls “addMacToMacFlow” twice. Based on the code, I assume in this implementation, the STP eliminate loops so all packets can be forwarded to all switchers. So only two flow entries could build a path between two MAC addresses.

But in my test, the MAC to MAC flow only be built when two hosts connected to the same switcher. This phenomenon really confuses me. I’m looking forward to your reply.

Thanks!

Junzhuo

The Minimum Spanning Tree is calculated to prevent loops in the network, those links that receive STP blocking status won't have flows written on them. FlowWriterServiceImpl.java in l2switch-main may have what you're looking for, it can create mac to mac flows, I'm not sure how robust the functionality is at the moment. 

On Thu, Aug 6, 2015 at 9:14 AM, Junzhuo Wang <wangjunzhuo200@...> wrote:

Hi André,

Thanks a lot for your reply! I’ve read the code from (https://github.com/opendaylight/l2switch/blob/master/loopremover/implementation/src/main/java/org/opendaylight/l2switch/loopremover/topology/NetworkGraphImpl.java#L123). The "getPath" method doesn’t exist anymore as you said. Also I did some tests and I found that the packets not always go through the shortest path. So I believe STP may be used as the current routing algorithm. If so, I can calculate the path by my self although it’s not a clean implementation. Let’s say what the code’s author says.

Junzhuo

Hi Junzhuo.
The code is here https://github.com/opendaylight/l2switch/tree/master/loopremover/implementation/src/main/java/org/opendaylight/l2switch/loopremover/topology
but I don't know if the service is working because of https://github.com/opendaylight/l2switch/blob/master/loopremover/implementation/src/main/java/org/opendaylight/l2switch/loopremover/topology/NetworkGraphService.java#L41
But I've send this email to the code's author to see what he says about it.
Best regards,
--André

On 06-08-2015 07:43, Junzhuo Wang wrote:

Hi all,

I’m a member from ODL/ALTO. I’m trying to find a API to compute the routing path between two hosts. So I read the code from openflowplugin, controller. It seems openflowplugin just set the flow table to switchers. And controller seems no longer handle the routing calculation now

 (org.opendaylight.controller.sal.routing doesn’t exist now).

Finally I found this page(https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:L2_Switch) saids that the l2switch now provide routing service. Which module should I use and how to get the route between two hosts by existing APIs?

Thanks,

Junzhuo

_______________________________________________
L2switch-dev mailing list
L2switch-dev@...https://lists.opendaylight.org/mailman/listinfo/l2switch-dev

--
Richard

Richard and Junzhuo,

I would highly encourage you to submit your enhancements to l2switch. Please start contributing the project. Submit your proposal for Beryllium release.  

-Amit

From: <yang.r.yang@...> on behalf of "Y. Richard Yang" <yry@...>
Date: Sunday, August 9, 2015 at 7:01 AM
To: Junzhuo Wang <wangjunzhuo200@...>
Cc: 陈明明 <mingmingminne@...>, Amit Mandke <ammandke@...>, Evan Zeller <evanrzeller@...>, André Martins <aanm90@...>, "Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIES at Cisco)" <ttkacik@...>, "l2switch-dev@..." <l2switch-dev@...>, Shu Dong <dongs2011@...>, "linxiao9292@..." <linxiao9292@...>, Jensen Zhang <jingxuan.n.zhang@...>, "gaok12@..." <gaok12@...>, "alto-dev@..." <alto-dev@...>, Andreas Voellmy <andreas.voellmy@...>, Shigang Zhu <szhu@...>
Subject: Re: How to compute the routing path between two hosts in OpenDayLight?

To add a bit, according to my understanding:

- current l2switch uses flooding based on a single, shared spanning. Hence, assume a switch with k neighbors in the spanning tree, it needs only k rules in its flow table: for each incoming neighbor, flood to the other k-1 neighbors. If we use the number of links traversed as cost when computing ECS, this routing scheme is not useful, because the cost for each arc-dst pair is the same. 

- As a first step, we develop l2switch-plus, which adds higher priority flow rules: for a given src, dst MAC pairs, we find the unicast path from the tree, and add <src-Mac, dst-Mac> entries to the flow tables. Note that this may cause flow table explosion, which we can look into:

* We identify compression. 

* Another idea is that when computing ECS, we do not insert the Mac rules. They are triggered by packet-in only. 

* Yet another idea is that ECS will insert the rules but with a relatively short timeout. Hence those rules not used by app will timeout quickly.

- In the next step, we use the ip-mac binding table to convert an l2 path to an l3 path.

In the long run, the preceding is not complete. For example, what if GBP reroutes a flow through middle boxes. The preceding derivation based on l2switch routing is not correct. We need to look into the composition approach of ODL.

Richard

On Sunday, August 9, 2015, Junzhuo Wang <wangjunzhuo200@...> wrote:

Hi Mingming,

The current status is that Dijkstra algorithm is not be used in l2switch. The related code are all been annotated. And the authors of l2switch also says this module is not complete. Instead, it use STP to forward all packets to every devices in the network. So we decide to develop our own module “l2switch-plus” to enhance the ability of l2switch. As a result, we can get routing information easily.

Best regards,

Junzhuo

Hi all,

I am sorry to come back so late. I sent email to cisco's stuff last Tuesday. He replied me as below:

"

Hi Mingming,
I am sure there is somewhere used the Dijkstra algorithm for this. I guess l2switch is the project involving this. You can check their wiki and eventually drop a question to their mailing list. Also you can read the topology and compute by yourself.


Regards,
"

I don't know how it goes now(I missed sync up on Saturday). I will try to find Dijkstra algorithm in ODL. And keep on asking for help from the helper? Or it has already resolved. I should do sth else? Thank you!

Best regards,

Mingming

在 2015-08-08 10:00:35，"Y. Richard Yang" <yry@...> 写道：

On Fri, Aug 7, 2015 at 8:16 PM, Amit Mandke (ammandke) <ammandke@...> wrote:

addMacToMac is not complete. Some more implementation is required to make it work. Never got a time to fix it. All contributions are welcome.

To clarify,  it is incomplete because it handles only the case of the same-switch, as implied by Junzhuo's testing? So the contribution is to handle cross-switch routing?

Thanks.

Richard

From: Junzhuo Wang <wangjunzhuo200@...>
Date: Friday, August 7, 2015 at 8:24 AM
To: Evan Zeller <evanrzeller@...>
Cc: André Martins <aanm90@...>, "Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIES at Cisco)" <ttkacik@...>, "l2switch-dev@..." <l2switch-dev@...>, Amit Mandke <ammandke@...>, Shu Dong <dongs2011@...>, "linxiao9292@..." <linxiao9292@...>, Jensen Zhang <jingxuan.n.zhang@...>, 陈明明 <mingmingminne@...>, "Y. Richard Yang" <yry@...>, "gaok12@..." <gaok12@...>
Subject: Re: [L2switch-dev] How to compute the routing path between two hosts in OpenDayLight?

A further question. Is there a layer 3 routing module could make OpenFlow switcher acts like a traditional router?

Thanks!

Junzhuo

Hi Evan,

It great to have your reply! I’ve seen that the method “addBidirectionalMacToMacFlows” calls “addMacToMacFlow” twice. Based on the code, I assume in this implementation, the STP eliminate loops so all packets can be forwarded to all switchers. So only two flow entries could build a path between two MAC addresses.

But in my test, the MAC to MAC flow only be built when two hosts connected to the same switcher. This phenomenon really confuses me. I’m looking forward to your reply.

Thanks!

Junzhuo

The Minimum Spanning Tree is calculated to prevent loops in the network, those links that receive STP blocking status won't have flows written on them. FlowWriterServiceImpl.java in l2switch-main may have what you're looking for, it can create mac to mac flows, I'm not sure how robust the functionality is at the moment. 

On Thu, Aug 6, 2015 at 9:14 AM, Junzhuo Wang <wangjunzhuo200@...> wrote:

Hi André,

Thanks a lot for your reply! I’ve read the code from (https://github.com/opendaylight/l2switch/blob/master/loopremover/implementation/src/main/java/org/opendaylight/l2switch/loopremover/topology/NetworkGraphImpl.java#L123). The "getPath" method doesn’t exist anymore as you said. Also I did some tests and I found that the packets not always go through the shortest path. So I believe STP may be used as the current routing algorithm. If so, I can calculate the path by my self although it’s not a clean implementation. Let’s say what the code’s author says.

Junzhuo

Hi Junzhuo.
The code is here https://github.com/opendaylight/l2switch/tree/master/loopremover/implementation/src/main/java/org/opendaylight/l2switch/loopremover/topology
but I don't know if the service is working because of https://github.com/opendaylight/l2switch/blob/master/loopremover/implementation/src/main/java/org/opendaylight/l2switch/loopremover/topology/NetworkGraphService.java#L41
But I've send this email to the code's author to see what he says about it.
Best regards,
--André

On 06-08-2015 07:43, Junzhuo Wang wrote:

Hi all,

I’m a member from ODL/ALTO. I’m trying to find a API to compute the routing path between two hosts. So I read the code from openflowplugin, controller. It seems openflowplugin just set the flow table to switchers. And controller seems no longer handle the routing calculation now

 (org.opendaylight.controller.sal.routing doesn’t exist now).

Finally I found this page(https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:L2_Switch) saids that the l2switch now provide routing service. Which module should I use and how to get the route between two hosts by existing APIs?

Thanks,

Junzhuo

_______________________________________________
L2switch-dev mailing list
L2switch-dev@...https://lists.opendaylight.org/mailman/listinfo/l2switch-dev

--
Richard

Richard and Junzhuo,

I would highly encourage you to submit your enhancements to l2switch. Please start contributing the project. Submit your proposal for Beryllium release.  

-Amit

From: <yang.r.yang@...> on behalf of "Y. Richard Yang" <yry@...>
Date: Sunday, August 9, 2015 at 7:01 AM
To: Junzhuo Wang <wangjunzhuo200@...>
Cc: 陈明明 <mingmingminne@...>, Amit Mandke <ammandke@...>, Evan Zeller <evanrzeller@...>, André Martins <aanm90@...>, "Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIES at Cisco)" <ttkacik@...>, "l2switch-dev@..." <l2switch-dev@...>, Shu Dong <dongs2011@...>, "linxiao9292@..." <linxiao9292@...>, Jensen Zhang <jingxuan.n.zhang@...>, "gaok12@..." <gaok12@...>, "alto-dev@..." <alto-dev@...>, Andreas Voellmy <andreas.voellmy@...>, Shigang Zhu <szhu@...>
Subject: Re: How to compute the routing path between two hosts in OpenDayLight?

To add a bit, according to my understanding:

- current l2switch uses flooding based on a single, shared spanning. Hence, assume a switch with k neighbors in the spanning tree, it needs only k rules in its flow table: for each incoming neighbor, flood to the other k-1 neighbors. If we use the number of links traversed as cost when computing ECS, this routing scheme is not useful, because the cost for each arc-dst pair is the same. 

- As a first step, we develop l2switch-plus, which adds higher priority flow rules: for a given src, dst MAC pairs, we find the unicast path from the tree, and add <src-Mac, dst-Mac> entries to the flow tables. Note that this may cause flow table explosion, which we can look into:

* We identify compression. 

* Another idea is that when computing ECS, we do not insert the Mac rules. They are triggered by packet-in only. 

* Yet another idea is that ECS will insert the rules but with a relatively short timeout. Hence those rules not used by app will timeout quickly.

- In the next step, we use the ip-mac binding table to convert an l2 path to an l3 path.

In the long run, the preceding is not complete. For example, what if GBP reroutes a flow through middle boxes. The preceding derivation based on l2switch routing is not correct. We need to look into the composition approach of ODL.

Richard

On Sunday, August 9, 2015, Junzhuo Wang <wangjunzhuo200@...> wrote:

Hi Mingming,

The current status is that Dijkstra algorithm is not be used in l2switch. The related code are all been annotated. And the authors of l2switch also says this module is not complete. Instead, it use STP to forward all packets to every devices in the network. So we decide to develop our own module “l2switch-plus” to enhance the ability of l2switch. As a result, we can get routing information easily.

Best regards,

Junzhuo

Hi all,

I am sorry to come back so late. I sent email to cisco's stuff last Tuesday. He replied me as below:

"

Hi Mingming,
I am sure there is somewhere used the Dijkstra algorithm for this. I guess l2switch is the project involving this. You can check their wiki and eventually drop a question to their mailing list. Also you can read the topology and compute by yourself.


Regards,
"

I don't know how it goes now(I missed sync up on Saturday). I will try to find Dijkstra algorithm in ODL. And keep on asking for help from the helper? Or it has already resolved. I should do sth else? Thank you!

Best regards,

Mingming

在 2015-08-08 10:00:35，"Y. Richard Yang" <yry@...> 写道：

On Fri, Aug 7, 2015 at 8:16 PM, Amit Mandke (ammandke) <ammandke@...> wrote:

addMacToMac is not complete. Some more implementation is required to make it work. Never got a time to fix it. All contributions are welcome.

To clarify,  it is incomplete because it handles only the case of the same-switch, as implied by Junzhuo's testing? So the contribution is to handle cross-switch routing?

Thanks.

Richard

From: Junzhuo Wang <wangjunzhuo200@...>
Date: Friday, August 7, 2015 at 8:24 AM
To: Evan Zeller <evanrzeller@...>
Cc: André Martins <aanm90@...>, "Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIES at Cisco)" <ttkacik@...>, "l2switch-dev@..." <l2switch-dev@...>, Amit Mandke <ammandke@...>, Shu Dong <dongs2011@...>, "linxiao9292@..." <linxiao9292@...>, Jensen Zhang <jingxuan.n.zhang@...>, 陈明明 <mingmingminne@...>, "Y. Richard Yang" <yry@...>, "gaok12@..." <gaok12@...>
Subject: Re: [L2switch-dev] How to compute the routing path between two hosts in OpenDayLight?

A further question. Is there a layer 3 routing module could make OpenFlow switcher acts like a traditional router?

Thanks!

Junzhuo

Hi Evan,

It great to have your reply! I’ve seen that the method “addBidirectionalMacToMacFlows” calls “addMacToMacFlow” twice. Based on the code, I assume in this implementation, the STP eliminate loops so all packets can be forwarded to all switchers. So only two flow entries could build a path between two MAC addresses.

But in my test, the MAC to MAC flow only be built when two hosts connected to the same switcher. This phenomenon really confuses me. I’m looking forward to your reply.

Thanks!

Junzhuo

The Minimum Spanning Tree is calculated to prevent loops in the network, those links that receive STP blocking status won't have flows written on them. FlowWriterServiceImpl.java in l2switch-main may have what you're looking for, it can create mac to mac flows, I'm not sure how robust the functionality is at the moment. 

On Thu, Aug 6, 2015 at 9:14 AM, Junzhuo Wang <wangjunzhuo200@...> wrote:

Hi André,

Thanks a lot for your reply! I’ve read the code from (https://github.com/opendaylight/l2switch/blob/master/loopremover/implementation/src/main/java/org/opendaylight/l2switch/loopremover/topology/NetworkGraphImpl.java#L123). The "getPath" method doesn’t exist anymore as you said. Also I did some tests and I found that the packets not always go through the shortest path. So I believe STP may be used as the current routing algorithm. If so, I can calculate the path by my self although it’s not a clean implementation. Let’s say what the code’s author says.

Junzhuo

Hi Junzhuo.
The code is here https://github.com/opendaylight/l2switch/tree/master/loopremover/implementation/src/main/java/org/opendaylight/l2switch/loopremover/topology
but I don't know if the service is working because of https://github.com/opendaylight/l2switch/blob/master/loopremover/implementation/src/main/java/org/opendaylight/l2switch/loopremover/topology/NetworkGraphService.java#L41
But I've send this email to the code's author to see what he says about it.
Best regards,
--André

On 06-08-2015 07:43, Junzhuo Wang wrote:

Hi all,

I’m a member from ODL/ALTO. I’m trying to find a API to compute the routing path between two hosts. So I read the code from openflowplugin, controller. It seems openflowplugin just set the flow table to switchers. And controller seems no longer handle the routing calculation now

 (org.opendaylight.controller.sal.routing doesn’t exist now).

Finally I found this page(https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:L2_Switch) saids that the l2switch now provide routing service. Which module should I use and how to get the route between two hosts by existing APIs?

Thanks,

Junzhuo

_______________________________________________
L2switch-dev mailing list
L2switch-dev@...https://lists.opendaylight.org/mailman/listinfo/l2switch-dev

--
Richard

 

 

Dear Richard,

 

It is out of question. Your suggestion is reasonable.

 

BR

G.Robert  Chen

 

From: yang.r.yang@... [mailto:yang.r.yang@...] On Behalf Of Y. Richard Yang
Sent: Friday, September 18, 2015 8:57 AM
To: Chenguohai
Cc: alto-dev@...; Wendy Roome; Xiao SHI; Xin Wang (Tongji)
Subject: Re: [alto-dev] Fwd: [OpenDaylight TSC] Fwd: Re: New committers

 

Robert,

 

It is great to have your contribution! I know that you have contributed an ALTO client when we conducted the previous interop in July. My feeling is that after we conduct a code review and you check in the client as a good part of ALTO/ODL, it will be a good base for you to become a committer. How does this sound? 

Wendy/Xin: what do you think?

 

Richard

 

On Thu, Sep 17, 2015 at 8:44 PM, Chenguohai <chenguohai@...> wrote:

 

 

Dear Richard,Wendy,Xiao,Xin,

 

Thanks.

I want to be committer and I shall do more on ALTO.

 

BR

G.Robert  Chen

 

From: alto-dev-bounces@... [mailto:alto-dev-bounces@...] On Behalf Of Y. Richard Yang
Sent: Thursday, September 17, 2015 11:11 PM
To: alto-dev@...; Wendy Roome; Xiao SHI; Xin Wang (Tongji)
Subject: [alto-dev] Fwd: [OpenDaylight TSC] Fwd: Re: New committers

 

Dear Wendy, Xiao, Xin,

 

May I propose the following changes to committers:

 

1. Proposal: Add Kai,  Shu, Jensen, as new committers. 

 

   Justification (copy from Kai's summary):
   "Jensen has submitted a lot of commits on improving the code quality [1] by writing tests and fixing bugs and he is now a key member of the development team. Kai ans Shu have implemented most components of ALTO Lithium release [2, 3].  They are also the actual project leaders of this project currently."

 

  Vote (please vote +1, 0, -1). My vote is +1

 

2. Proposal: Add Guohai as a new committer after ALTO client check in:

  

   Justification: Guohai has made substantial contribution to write an ALTO client. If we  check in as part of the ALTO project, we should include Guohai (Robert) as a committer. Robert: Do you want to do so?

 

  Vote: Pending Guohai check in.

 

3. Proposal: Add Junzhuo as a new committer after new ALTO version check in.

  Vote: Pending Junzhuo check in.

 

4. Remove Xiao from the committers, as Xiao no longer participates in the ALTO project.

 

  Vote: +1

 

Please share your opinions when you can.

 

Thanks.

Richard

 

[1] https://git.opendaylight.org/gerrit/#/q/project:alto+owner:jensenzhang

[2] https://git.opendaylight.org/gerrit/#/q/owner:gaok12%40mails.tsinghua.edu.cn+status:merged+project:alto

[3] https://git.opendaylight.org/gerrit/#/q/owner:dongshu+status:merged+project:alto

 

---------- Forwarded message ----------
From: Y. Richard Yang <yry@...>
Date: Thu, Sep 17, 2015 at 10:58 AM
Subject: Re: [alto-dev] [OpenDaylight TSC] Fwd: Re: New committers
To: Colin Dixon <colin@...>
Cc: Gao Kai <gaok12@...>, "alto-dev@..." <alto-dev@...>

Colin,

 

On Thu, Sep 17, 2015 at 10:50 AM, Colin Dixon <colin@...> wrote:

So, when the project proposal was approved, it was this:
https://wiki.opendaylight.org/index.php?title=Project_Proposals:Alto&oldid=25169

There were 4 committers listed:
* Xiao Shi (Shixiao) (Yale University)
* Xin (Tony) Wang (Tonywang) (Tongji University)
* Y. Richard Yang (Yrichardyang) (Yale/Tongji University)
* Wendy Roome (Wdroome) (Bell Labs)

Those four people should have full committer rights in gerrit and should also be voting members of the project when it comes to adding new committers.

Along those lines, I have 3 requests:
1.) Remove Huaming Guo as an initial committer fomr the project proposal, since he wasn't one.
2.) If it's possible get the other current committers (Xiao, Xin, and Wendy) to vote on the newly proposed committers.
3.) Remove the new committers (Shu, Kai, Guohai, and Yichen) from the main page until they are voted on by the project committers and approved by the TSC.

 

 

The three requests make sense. Let us follow the procedure and get them done soon.

 

Thanks for the guidance!

Richard

 

Let me know if that makes sense.

--Colin

 

On Fri, Sep 11, 2015 at 3:48 PM, Y. Richard Yang <yry@...> wrote:

Hi Colin,

 

On Fri, Sep 11, 2015 at 2:48 PM, Colin Dixon <colin@...> wrote:

Out of curiosity, what do you mean when you say "Richard, the only committer of ALTO project at the moment"?

As I see it you have 8 committers listed here:
https://wiki.opendaylight.org/view/ALTO:Main

 

I think there is a misunderstanding here. When we listed the names on the preceding Web page, we thought those names would be contributors, i.e., they would participate in the project, but without the ability to commit in the sense of git approval. Hence, I am the only git committer/approver. This also explains why we added Huaming without seeking the approval of TSC. Does this clarify?

 

Richard

 

 

That's also odd because you only have 5 initial committers listed here and I don't remember the TSC approving more:
https://wiki.opendaylight.org/view/Project_Proposals:Alto#Initial_Committers

More odd is that you seem to have added  Huaming Guo as an initial committer after the project was approved on January 8th:
https://wiki.opendaylight.org/index.php?title=Project_Proposals%3AAlto&diff=26601&oldid=25169

 

--Colin

 

On Thu, Sep 10, 2015 at 10:53 PM, Gao Kai <gaok12@...> wrote:

Dear TSC,

We have carried out a public vote for three new committers in ALTO project [0].  Richard, the only committer of ALTO project at the moment, has voted +1 for all three candidates.

[0] https://lists.opendaylight.org/pipermail/alto-dev/2015-September/000217.html

Regards,
Kai

-------- Forwarded Message --------

Subject:	Re: New committers
Date:	Thu, 10 Sep 2015 22:33:06 -0400
From:	Y. Richard Yang <yry@...>
To:	Gao Kai <gaok12@...>
CC:	alto-dev@... <alto-dev@...>, 张敬轩 <jingxuan.n.zhang@...>, Shu Dong <dongs2011@...>

Dear Kai,

 

I sure am impressed by the work of you three. As main contributors of the ALTO project, I support you three to become commiters to move the project further:

Jensen: +1

Kai: +1

Shu: +1

 

Richard

On Thursday, September 10, 2015, Gao Kai <gaok12@...> wrote:

Hi Richard and all,

I'd like to nominate three new committers for the ALTO project: Jensen, Kai and Shu.

Jensen has submitted a lot of commits on improving the code quality [1] by writing tests and fixing bugs and he is now a key member of the development team.

Kai ans Shu have implemented most components of ALTO Lithium release [2, 3].  They are also the actual project leaders of this project currently.

[1] https://git.opendaylight.org/gerrit/#/q/project:alto+owner:jensenzhang
[2] https://git.opendaylight.org/gerrit/#/q/owner:gaok12%40mails.tsinghua.edu.cn+status:merged+project:alto
[3] https://git.opendaylight.org/gerrit/#/q/owner:dongshu+status:merged+project:alto

Committers please vote +1, 0 or -1 for each of these developers.

Thanks.

Kai

--
Richard

 

 

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

 

 

_______________________________________________
alto-dev mailing list
alto-dev@...
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.opendaylight.org_mailman_listinfo_alto-2Ddev&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=nomUG6iXrvN5BBRA5FIhGJR3lzVqaO8KVxV0uCZ19nU&s=bZtQA2esJKKZvoNjIjYspsvxPyXb2NsiuGECN5qlj0U&e=

 

 

--

-- 

 =====================================

| Y. Richard Yang <yry@...>   |

| Professor of Computer Science       |

| http://www.cs.yale.edu/~yry/        |

 =====================================

--

 

 

Dear Richard,Wendy,Xiao,Xin,

 

Thanks.

I want to be committer and I shall do more on ALTO.

 

BR

G.Robert  Chen

 

From: alto-dev-bounces@... [mailto:alto-dev-bounces@...] On Behalf Of Y. Richard Yang
Sent: Thursday, September 17, 2015 11:11 PM
To: alto-dev@...; Wendy Roome; Xiao SHI; Xin Wang (Tongji)
Subject: [alto-dev] Fwd: [OpenDaylight TSC] Fwd: Re: New committers

 

Dear Wendy, Xiao, Xin,

 

May I propose the following changes to committers:

 

1. Proposal: Add Kai,  Shu, Jensen, as new committers. 

 

   Justification (copy from Kai's summary):
   "Jensen has submitted a lot of commits on improving the code quality [1] by writing tests and fixing bugs and he is now a key member of the development team. Kai ans Shu have implemented most components of ALTO Lithium release [2, 3].  They are also the actual project leaders of this project currently."

 

  Vote (please vote +1, 0, -1). My vote is +1

 

2. Proposal: Add Guohai as a new committer after ALTO client check in:

  

   Justification: Guohai has made substantial contribution to write an ALTO client. If we  check in as part of the ALTO project, we should include Guohai (Robert) as a committer. Robert: Do you want to do so?

 

  Vote: Pending Guohai check in.

 

3. Proposal: Add Junzhuo as a new committer after new ALTO version check in.

  Vote: Pending Junzhuo check in.

 

4. Remove Xiao from the committers, as Xiao no longer participates in the ALTO project.

 

  Vote: +1

 

Please share your opinions when you can.

 

Thanks.

Richard

 

[1] https://git.opendaylight.org/gerrit/#/q/project:alto+owner:jensenzhang

[2] https://git.opendaylight.org/gerrit/#/q/owner:gaok12%40mails.tsinghua.edu.cn+status:merged+project:alto

[3] https://git.opendaylight.org/gerrit/#/q/owner:dongshu+status:merged+project:alto

 

---------- Forwarded message ----------
From: Y. Richard Yang <yry@...>
Date: Thu, Sep 17, 2015 at 10:58 AM
Subject: Re: [alto-dev] [OpenDaylight TSC] Fwd: Re: New committers
To: Colin Dixon <colin@...>
Cc: Gao Kai <gaok12@...>, "alto-dev@..." <alto-dev@...>

Colin,

 

On Thu, Sep 17, 2015 at 10:50 AM, Colin Dixon <colin@...> wrote:

So, when the project proposal was approved, it was this:
https://wiki.opendaylight.org/index.php?title=Project_Proposals:Alto&oldid=25169

There were 4 committers listed:
* Xiao Shi (Shixiao) (Yale University)
* Xin (Tony) Wang (Tonywang) (Tongji University)
* Y. Richard Yang (Yrichardyang) (Yale/Tongji University)
* Wendy Roome (Wdroome) (Bell Labs)

Those four people should have full committer rights in gerrit and should also be voting members of the project when it comes to adding new committers.

Along those lines, I have 3 requests:
1.) Remove Huaming Guo as an initial committer fomr the project proposal, since he wasn't one.
2.) If it's possible get the other current committers (Xiao, Xin, and Wendy) to vote on the newly proposed committers.
3.) Remove the new committers (Shu, Kai, Guohai, and Yichen) from the main page until they are voted on by the project committers and approved by the TSC.

 

 

The three requests make sense. Let us follow the procedure and get them done soon.

 

Thanks for the guidance!

Richard

 

Let me know if that makes sense.

--Colin

 

On Fri, Sep 11, 2015 at 3:48 PM, Y. Richard Yang <yry@...> wrote:

Hi Colin,

 

On Fri, Sep 11, 2015 at 2:48 PM, Colin Dixon <colin@...> wrote:

Out of curiosity, what do you mean when you say "Richard, the only committer of ALTO project at the moment"?

As I see it you have 8 committers listed here:
https://wiki.opendaylight.org/view/ALTO:Main

 

I think there is a misunderstanding here. When we listed the names on the preceding Web page, we thought those names would be contributors, i.e., they would participate in the project, but without the ability to commit in the sense of git approval. Hence, I am the only git committer/approver. This also explains why we added Huaming without seeking the approval of TSC. Does this clarify?

 

Richard

 

 

That's also odd because you only have 5 initial committers listed here and I don't remember the TSC approving more:
https://wiki.opendaylight.org/view/Project_Proposals:Alto#Initial_Committers

More odd is that you seem to have added  Huaming Guo as an initial committer after the project was approved on January 8th:
https://wiki.opendaylight.org/index.php?title=Project_Proposals%3AAlto&diff=26601&oldid=25169

 

--Colin

 

On Thu, Sep 10, 2015 at 10:53 PM, Gao Kai <gaok12@...> wrote:

Dear TSC,

We have carried out a public vote for three new committers in ALTO project [0].  Richard, the only committer of ALTO project at the moment, has voted +1 for all three candidates.

[0] https://lists.opendaylight.org/pipermail/alto-dev/2015-September/000217.html

Regards,
Kai

-------- Forwarded Message --------

Subject:	Re: New committers
Date:	Thu, 10 Sep 2015 22:33:06 -0400
From:	Y. Richard Yang <yry@...>
To:	Gao Kai <gaok12@...>
CC:	alto-dev@... <alto-dev@...>, 张敬轩 <jingxuan.n.zhang@...>, Shu Dong <dongs2011@...>

Dear Kai,

 

I sure am impressed by the work of you three. As main contributors of the ALTO project, I support you three to become commiters to move the project further:

Jensen: +1

Kai: +1

Shu: +1

 

Richard

On Thursday, September 10, 2015, Gao Kai <gaok12@...> wrote:

Hi Richard and all,

I'd like to nominate three new committers for the ALTO project: Jensen, Kai and Shu.

Jensen has submitted a lot of commits on improving the code quality [1] by writing tests and fixing bugs and he is now a key member of the development team.

Kai ans Shu have implemented most components of ALTO Lithium release [2, 3].  They are also the actual project leaders of this project currently.

[1] https://git.opendaylight.org/gerrit/#/q/project:alto+owner:jensenzhang
[2] https://git.opendaylight.org/gerrit/#/q/owner:gaok12%40mails.tsinghua.edu.cn+status:merged+project:alto
[3] https://git.opendaylight.org/gerrit/#/q/owner:dongshu+status:merged+project:alto

Committers please vote +1, 0 or -1 for each of these developers.

Thanks.

Kai

--
Richard

 

 

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

 

 

_______________________________________________
alto-dev mailing list
alto-dev@...
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.opendaylight.org_mailman_listinfo_alto-2Ddev&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=nomUG6iXrvN5BBRA5FIhGJR3lzVqaO8KVxV0uCZ19nU&s=bZtQA2esJKKZvoNjIjYspsvxPyXb2NsiuGECN5qlj0U&e=

 

--

So, when the project proposal was approved, it was this:
https://wiki.opendaylight.org/index.php?title=Project_Proposals:Alto&oldid=25169

There were 4 committers listed:
* Xiao Shi (Shixiao) (Yale University)
* Xin (Tony) Wang (Tonywang) (Tongji University)
* Y. Richard Yang (Yrichardyang) (Yale/Tongji University)
* Wendy Roome (Wdroome) (Bell Labs)

Those four people should have full committer rights in gerrit and should also be voting members of the project when it comes to adding new committers.

Along those lines, I have 3 requests:
1.) Remove Huaming Guo as an initial committer fomr the project proposal, since he wasn't one.
2.) If it's possible get the other current committers (Xiao, Xin, and Wendy) to vote on the newly proposed committers.
3.) Remove the new committers (Shu, Kai, Guohai, and Yichen) from the main page until they are voted on by the project committers and approved by the TSC.