Hi Richard,

I didn’t understand if alto-manager deletes alto-hosttracker-generated data (i think delete is only action it can do), how alto-hosttracker reacts?

1. it stops listening to l2switch and waits for alto-manager’s next command (like restart)?
2. it continues listening to l2switch and just adds new data to data store? (it’s like option 1’s restart, but it keeps history data about existing hosts)
3. some other choices?

Thanks,

Xin

Shu,

Thanks for the update! Please see below.

On Tue, Apr 21, 2015 at 11:12 PM, 董舒 <dongs2011@...> wrote:

Actually I posted my progress in slack but it seems that no one was on it, so I will post it here:

Most of the alto-manager code has been done during the last weekend. The code review link: https://git.opendaylight.org/gerrit/18601 . However, the code logic for cost map and endpoint property map is not done yet since currently alto-commons does not support converting from rfc cost-map/endpoint property-map json to the one with yang model encoding, and vice versa (which means it only supports network-map now). Since kai is busy this week, I wrote the converter for the cost-map yesterday by myself but have not tested and pushed the code. I'm expecting to finish the endpoint property map part tonight.

Great!

 

After that I will finalize alto-manger and then help with @xinli to write the test cases with robot framework. I'm expecting to finished all the test cases related to alto-manager this week.

 

Thanks. 

 

Also, I had a long offline discussions with @xinwang about cost field of cost map. Things become a little complicated when it comes to cost field of cost map. If we use augmentation for cost field, alto-commons will depend on the project where the augmentation defined to convert cost-map json string to proper java object, that is to say, here, alto-commons is depending on alto-hosttracker. So could anyone code review and approve the code @xinwang just pushed last weekend so we could use his code?

I will review tomorrow.

 

Also, although using the augmentation, i think defining a default cost field in alto-model is necessary. Currently what we did is just deleting the field from alto-model and defining it in some other projects by augmentation.

Let me understand. What is a goal of defining a default cost field? Or you are suggesting that there is a default cost field, say numerical, and then use augment to change (or add) it into another type, when it is, say, ordinal? My understanding is that augment can only add (https://tools.ietf.org/html/rfc6020#section-7.15). 

For efficient storage, in terms of Java classes, I feel that a possible definition of a cost-map is the following:

Inner level is from string (dst pid name) to the type such as a float (numerical) or int (ordinal) or vector (path-vector): HashMap<String, Integer> or HashMap<String, Double> or HashMap<String, Vector>, ..

Outer level is a hash map from string (src pidname) to the inner level hashmap, e.g.,
HashMap<String, HashMap<String, ValueType>>

A very dumb inheritance based design is is:

class CostMapBase {

  // base field (meta)

}

class CostMapInt extends CostMapBase {

  HashMap<String, Integer> costmap;

}

class CostMapDouble extends CostMapBase {

  HashMap<String, Double> costmap;

}

Or if one uses the containment design:

class CostMap<ValueType> {

  // meta

 HashMap<String, HashMap<String, ValueType>> costmap;

}

I believe that the augment mapping is based on inheritance. Hence, to simulate the first design, the augment defines the whole hashmap of hashmap. Make sense?

Richard 

On Wed, Apr 22, 2015 at 9:15 AM, Y. Richard Yang <yry@...> wrote:

Dear team,

Just in case you are wondering on the quietness of this team, since Kai and Xin Wang are in ODL training, I feel that it is OK to slow down a bit this week. After this week, we will have 2.5 weeks to finalize (Code Free May 14). I am taking advantage of this time to handle a few other issues and read up on ONOS, to see how much of our work can be designed to be general, i.e., portable to ONOS as well, so that we go do a final code refactoring, if needed. 

To avoid to much idle, can one of you (Shu and Xin Li) send out an update on the current status, in particular the missing pieces in terms of finishing T1-T6, so that Wendy and I can start to review the code and help?

Shu/Xin: Could you please send this soon?

Thanks a lot!

Richard

Me too, i will be available at Friday night.

---

Date: Thu, 23 Apr 2015 09:04:13 +0800
From: gaok12@...
To: yry@...
CC: dongs2011@...; yakumolx@...; xinwang2014@...; wendy@...; alto-dev@...
Subject: Re: Re: ALTO in ODL Planning

Won't be available until Friday night.

-----原始邮件-----
发件人: "Y. Richard Yang" <yry@...>
发送时间: 2015-04-22 21:09:09 (星期三)
收件人: "董舒" <dongs2011@...>
抄送: "Kai Gao" <gaok12@...>, "Xin Li" <yakumolx@...>, "Xin Wang (Tongji)" <xinwang2014@...>, "Wendy Roome" <wendy@...>, "alto-dev@..." <alto-dev@...>
主题: Re: ALTO in ODL Planning

Hi Shu,

Let's schedule a design meeting soon. It depends on when Xin and Kai are available.

Xin/Kai: please let us know.

Let me summarize the option, if we use yang (BTW: I always think using yang is a wrong design decision, because it does not add much free ride but add much restriction, at least for a programmer, :-(

Here is the proposal: Base cost-map includes only meta; depends on cost-metric, we add (augment) the correct hash map. This is to simulate the inheritance design in my previous email (base class has only meta and each derived class has the correct HashMap of HashMap; note there is a typo in the previous email, which I fixed in this reply). I will take a look at Jackson to see how it handles such stateful parsing.

I thought about a yang storage model where each cost value is always a float (this is allowed by the Java promotion rule), but it is a hack that will fall apart when we add vector.

Thanks.

Richard 

On Wednesday, April 22, 2015, 董舒 <dongs2011@...> wrote:

Sorry for the late reply. Just come back from office.

Actually I don't have a solution for the default cost field problem but the intuition told me that we should set a default cost field in alto-model instead of leave it as empty. I think your design is very good, but I have no idea how to implement it by yang. Do you think it's necessary to schedule a meeting to discuss it together?

On Wed, Apr 22, 2015 at 12:48 PM, Y. Richard Yang <yry@...> wrote:

Shu,

Thanks for the update! Please see below.

On Tue, Apr 21, 2015 at 11:12 PM, 董舒 <dongs2011@...> wrote:

Actually I posted my progress in slack but it seems that no one was on it, so I will post it here:

Most of the alto-manager code has been done during the last weekend. The code review link: https://git.opendaylight.org/gerrit/18601 . However, the code logic for cost map and endpoint property map is not done yet since currently alto-commons does not support converting from rfc cost-map/endpoint property-map json to the one with yang model encoding, and vice versa (which means it only supports network-map now). Since kai is busy this week, I wrote the converter for the cost-map yesterday by myself but have not tested and pushed the code. I'm expecting to finish the endpoint property map part tonight.

Great!

 

After that I will finalize alto-manger and then help with @xinli to write the test cases with robot framework. I'm expecting to finished all the test cases related to alto-manager this week.

 

Thanks. 

 

Also, I had a long offline discussions with @xinwang about cost field of cost map. Things become a little complicated when it comes to cost field of cost map. If we use augmentation for cost field, alto-commons will depend on the project where the augmentation defined to convert cost-map json string to proper java object, that is to say, here, alto-commons is depending on alto-hosttracker. So could anyone code review and approve the code @xinwang just pushed last weekend so we could use his code?

I will review tomorrow.

 

Also, although using the augmentation, i think defining a default cost field in alto-model is necessary. Currently what we did is just deleting the field from alto-model and defining it in some other projects by augmentation.

Let me understand. What is a goal of defining a default cost field? Or you are suggesting that there is a default cost field, say numerical, and then use augment to change (or add) it into another type, when it is, say, ordinal? My understanding is that augment can only add (https://tools.ietf.org/html/rfc6020#section-7.15). 

For efficient storage, in terms of Java classes, I feel that a possible definition of a cost-map is the following:

Inner level is from string (dst pid name) to the type such as a float (numerical) or int (ordinal) or vector (path-vector): HashMap<String, Integer> or HashMap<String, Double> or HashMap<String, Vector>, ..

Outer level is a hash map from string (src pidname) to the inner level hashmap, e.g.,
HashMap<String, HashMap<String, ValueType>>

A very dumb inheritance based design is is:

class CostMapBase {

  // base field (meta)

}

class CostMapInt extends CostMapBase {

  HashMap<String, HashMap<String, Integer>> costmap;

}

class CostMapDouble extends CostMapBase {

  HashMap<String, HashMap<String, Double>> costmap;

}

Or if one uses the containment design:

class CostMap<ValueType> {

  // meta

 HashMap<String, HashMap<String, ValueType>> costmap;

}

I believe that the augment mapping is based on inheritance. Hence, to simulate the first design, the augment defines the whole hashmap of hashmap. Make sense?

Richard 

On Wed, Apr 22, 2015 at 9:15 AM, Y. Richard Yang <yry@...> wrote:

Dear team,

Just in case you are wondering on the quietness of this team, since Kai and Xin Wang are in ODL training, I feel that it is OK to slow down a bit this week. After this week, we will have 2.5 weeks to finalize (Code Free May 14). I am taking advantage of this time to handle a few other issues and read up on ONOS, to see how much of our work can be designed to be general, i.e., portable to ONOS as well, so that we go do a final code refactoring, if needed. 

To avoid to much idle, can one of you (Shu and Xin Li) send out an update on the current status, in particular the missing pieces in terms of finishing T1-T6, so that Wendy and I can start to review the code and help?

Shu/Xin: Could you please send this soon?

Thanks a lot!

Richard

--
Richard

OK. Let's plan Saturday morning your time (Friday evening my time). Let's set 10 am your time. How does this sound?

Richard

On Wed, Apr 22, 2015 at 9:10 PM, wangxin <xinwang2014@...> wrote:

Me too, i will be available at Friday night.

---

Date: Thu, 23 Apr 2015 09:04:13 +0800
From: gaok12@...
To: yry@...
CC: dongs2011@...; yakumolx@...; xinwang2014@...; wendy@...; alto-dev@...
Subject: Re: Re: ALTO in ODL Planning

Won't be available until Friday night.

-----原始邮件-----
发件人: "Y. Richard Yang" <yry@...>
发送时间: 2015-04-22 21:09:09 (星期三)
收件人: "董舒" <dongs2011@...>
抄送: "Kai Gao" <gaok12@...>, "Xin Li" <yakumolx@...>, "Xin Wang (Tongji)" <xinwang2014@...>, "Wendy Roome" <wendy@...>, "alto-dev@..." <alto-dev@...>
主题: Re: ALTO in ODL Planning

Hi Shu,

Let's schedule a design meeting soon. It depends on when Xin and Kai are available.

Xin/Kai: please let us know.

Let me summarize the option, if we use yang (BTW: I always think using yang is a wrong design decision, because it does not add much free ride but add much restriction, at least for a programmer, :-(

Here is the proposal: Base cost-map includes only meta; depends on cost-metric, we add (augment) the correct hash map. This is to simulate the inheritance design in my previous email (base class has only meta and each derived class has the correct HashMap of HashMap; note there is a typo in the previous email, which I fixed in this reply). I will take a look at Jackson to see how it handles such stateful parsing.

I thought about a yang storage model where each cost value is always a float (this is allowed by the Java promotion rule), but it is a hack that will fall apart when we add vector.

Thanks.

Richard 

On Wednesday, April 22, 2015, 董舒 <dongs2011@...> wrote:

Sorry for the late reply. Just come back from office.

Actually I don't have a solution for the default cost field problem but the intuition told me that we should set a default cost field in alto-model instead of leave it as empty. I think your design is very good, but I have no idea how to implement it by yang. Do you think it's necessary to schedule a meeting to discuss it together?

On Wed, Apr 22, 2015 at 12:48 PM, Y. Richard Yang <yry@...> wrote:

Shu,

Thanks for the update! Please see below.

On Tue, Apr 21, 2015 at 11:12 PM, 董舒 <dongs2011@...> wrote:

Actually I posted my progress in slack but it seems that no one was on it, so I will post it here:

Most of the alto-manager code has been done during the last weekend. The code review link: https://git.opendaylight.org/gerrit/18601 . However, the code logic for cost map and endpoint property map is not done yet since currently alto-commons does not support converting from rfc cost-map/endpoint property-map json to the one with yang model encoding, and vice versa (which means it only supports network-map now). Since kai is busy this week, I wrote the converter for the cost-map yesterday by myself but have not tested and pushed the code. I'm expecting to finish the endpoint property map part tonight.

Great!

 

After that I will finalize alto-manger and then help with @xinli to write the test cases with robot framework. I'm expecting to finished all the test cases related to alto-manager this week.

 

Thanks. 

 

Also, I had a long offline discussions with @xinwang about cost field of cost map. Things become a little complicated when it comes to cost field of cost map. If we use augmentation for cost field, alto-commons will depend on the project where the augmentation defined to convert cost-map json string to proper java object, that is to say, here, alto-commons is depending on alto-hosttracker. So could anyone code review and approve the code @xinwang just pushed last weekend so we could use his code?

I will review tomorrow.

 

Also, although using the augmentation, i think defining a default cost field in alto-model is necessary. Currently what we did is just deleting the field from alto-model and defining it in some other projects by augmentation.

Let me understand. What is a goal of defining a default cost field? Or you are suggesting that there is a default cost field, say numerical, and then use augment to change (or add) it into another type, when it is, say, ordinal? My understanding is that augment can only add (https://tools.ietf.org/html/rfc6020#section-7.15). 

For efficient storage, in terms of Java classes, I feel that a possible definition of a cost-map is the following:

Inner level is from string (dst pid name) to the type such as a float (numerical) or int (ordinal) or vector (path-vector): HashMap<String, Integer> or HashMap<String, Double> or HashMap<String, Vector>, ..

Outer level is a hash map from string (src pidname) to the inner level hashmap, e.g.,
HashMap<String, HashMap<String, ValueType>>

A very dumb inheritance based design is is:

class CostMapBase {

  // base field (meta)

}

class CostMapInt extends CostMapBase {

  HashMap<String, HashMap<String, Integer>> costmap;

}

class CostMapDouble extends CostMapBase {

  HashMap<String, HashMap<String, Double>> costmap;

}

Or if one uses the containment design:

class CostMap<ValueType> {

  // meta

 HashMap<String, HashMap<String, ValueType>> costmap;

}

I believe that the augment mapping is based on inheritance. Hence, to simulate the first design, the augment defines the whole hashmap of hashmap. Make sense?

Richard 

On Wed, Apr 22, 2015 at 9:15 AM, Y. Richard Yang <yry@...> wrote:

Dear team,

Just in case you are wondering on the quietness of this team, since Kai and Xin Wang are in ODL training, I feel that it is OK to slow down a bit this week. After this week, we will have 2.5 weeks to finalize (Code Free May 14). I am taking advantage of this time to handle a few other issues and read up on ONOS, to see how much of our work can be designed to be general, i.e., portable to ONOS as well, so that we go do a final code refactoring, if needed. 

To avoid to much idle, can one of you (Shu and Xin Li) send out an update on the current status, in particular the missing pieces in terms of finishing T1-T6, so that Wendy and I can start to review the code and help?

Shu/Xin: Could you please send this soon?

Thanks a lot!

Richard

--
Richard

--

-- 

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

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

| Professor of Computer Science       |

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

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

OK. Let's plan Saturday morning your time (Friday evening my time). Let's set 10 am your time. How does this sound?

Richard

On Wed, Apr 22, 2015 at 9:10 PM, wangxin <xinwang2014@...> wrote:

Me too, i will be available at Friday night.

---

Date: Thu, 23 Apr 2015 09:04:13 +0800
From: gaok12@...
To: yry@...
CC: dongs2011@...; yakumolx@...; xinwang2014@...; wendy@...; alto-dev@...
Subject: Re: Re: ALTO in ODL Planning

Won't be available until Friday night.

-----原始邮件-----
发件人: "Y. Richard Yang" <yry@...>
发送时间: 2015-04-22 21:09:09 (星期三)
收件人: "董舒" <dongs2011@...>
抄送: "Kai Gao" <gaok12@...>, "Xin Li" <yakumolx@...>, "Xin Wang (Tongji)" <xinwang2014@...>, "Wendy Roome" <wendy@...>, "alto-dev@..." <alto-dev@...>
主题: Re: ALTO in ODL Planning

Hi Shu,

Let's schedule a design meeting soon. It depends on when Xin and Kai are available.

Xin/Kai: please let us know.

Let me summarize the option, if we use yang (BTW: I always think using yang is a wrong design decision, because it does not add much free ride but add much restriction, at least for a programmer, :-(

Here is the proposal: Base cost-map includes only meta; depends on cost-metric, we add (augment) the correct hash map. This is to simulate the inheritance design in my previous email (base class has only meta and each derived class has the correct HashMap of HashMap; note there is a typo in the previous email, which I fixed in this reply). I will take a look at Jackson to see how it handles such stateful parsing.

I thought about a yang storage model where each cost value is always a float (this is allowed by the Java promotion rule), but it is a hack that will fall apart when we add vector.

Thanks.

Richard 

On Wednesday, April 22, 2015, 董舒 <dongs2011@...> wrote:

Sorry for the late reply. Just come back from office.

Actually I don't have a solution for the default cost field problem but the intuition told me that we should set a default cost field in alto-model instead of leave it as empty. I think your design is very good, but I have no idea how to implement it by yang. Do you think it's necessary to schedule a meeting to discuss it together?

On Wed, Apr 22, 2015 at 12:48 PM, Y. Richard Yang <yry@...> wrote:

Shu,

Thanks for the update! Please see below.

On Tue, Apr 21, 2015 at 11:12 PM, 董舒 <dongs2011@...> wrote:

Actually I posted my progress in slack but it seems that no one was on it, so I will post it here:

Most of the alto-manager code has been done during the last weekend. The code review link: https://git.opendaylight.org/gerrit/18601 . However, the code logic for cost map and endpoint property map is not done yet since currently alto-commons does not support converting from rfc cost-map/endpoint property-map json to the one with yang model encoding, and vice versa (which means it only supports network-map now). Since kai is busy this week, I wrote the converter for the cost-map yesterday by myself but have not tested and pushed the code. I'm expecting to finish the endpoint property map part tonight.

Great!

 

After that I will finalize alto-manger and then help with @xinli to write the test cases with robot framework. I'm expecting to finished all the test cases related to alto-manager this week.

 

Thanks. 

 

Also, I had a long offline discussions with @xinwang about cost field of cost map. Things become a little complicated when it comes to cost field of cost map. If we use augmentation for cost field, alto-commons will depend on the project where the augmentation defined to convert cost-map json string to proper java object, that is to say, here, alto-commons is depending on alto-hosttracker. So could anyone code review and approve the code @xinwang just pushed last weekend so we could use his code?

I will review tomorrow.

 

Also, although using the augmentation, i think defining a default cost field in alto-model is necessary. Currently what we did is just deleting the field from alto-model and defining it in some other projects by augmentation.

Let me understand. What is a goal of defining a default cost field? Or you are suggesting that there is a default cost field, say numerical, and then use augment to change (or add) it into another type, when it is, say, ordinal? My understanding is that augment can only add (https://tools.ietf.org/html/rfc6020#section-7.15). 

For efficient storage, in terms of Java classes, I feel that a possible definition of a cost-map is the following:

Inner level is from string (dst pid name) to the type such as a float (numerical) or int (ordinal) or vector (path-vector): HashMap<String, Integer> or HashMap<String, Double> or HashMap<String, Vector>, ..

Outer level is a hash map from string (src pidname) to the inner level hashmap, e.g.,
HashMap<String, HashMap<String, ValueType>>

A very dumb inheritance based design is is:

class CostMapBase {

  // base field (meta)

}

class CostMapInt extends CostMapBase {

  HashMap<String, HashMap<String, Integer>> costmap;

}

class CostMapDouble extends CostMapBase {

  HashMap<String, HashMap<String, Double>> costmap;

}

Or if one uses the containment design:

class CostMap<ValueType> {

  // meta

 HashMap<String, HashMap<String, ValueType>> costmap;

}

I believe that the augment mapping is based on inheritance. Hence, to simulate the first design, the augment defines the whole hashmap of hashmap. Make sense?

Richard 

On Wed, Apr 22, 2015 at 9:15 AM, Y. Richard Yang <yry@...> wrote:

Dear team,

Just in case you are wondering on the quietness of this team, since Kai and Xin Wang are in ODL training, I feel that it is OK to slow down a bit this week. After this week, we will have 2.5 weeks to finalize (Code Free May 14). I am taking advantage of this time to handle a few other issues and read up on ONOS, to see how much of our work can be designed to be general, i.e., portable to ONOS as well, so that we go do a final code refactoring, if needed. 

To avoid to much idle, can one of you (Shu and Xin Li) send out an update on the current status, in particular the missing pieces in terms of finishing T1-T6, so that Wendy and I can start to review the code and help?

Shu/Xin: Could you please send this soon?

Thanks a lot!

Richard

--
Richard

--

-- 

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

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

| Professor of Computer Science       |

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

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