Date   

Re: Few questions on ALTO and ONOS

MD I. Islam <mislam4@...>
 

Yeah, interested. Is that the Endpoint Cost Service? What are the metrics we are considering?

On Fri, Jul 17, 2015 at 12:45 PM, Y. Richard Yang <yry@...> wrote:
Dear Tamim,

Wonderful! 

Per my personal wish list, a main feature that I want to improve on is high quality ECS service, based on various metrics. Any interest?

Richard

On Sat, Jul 18, 2015 at 12:35 AM, MD I. Islam <mislam4@...> wrote:
Yeah, sure. I'm interested on adding features to the ALTO ODL server. Please let me know what you want me to do.

Thanks
Tamim

On Fri, Jul 17, 2015 at 12:12 PM, Y. Richard Yang <yry@...> wrote:
Dear Tamim,

Thanks a lot for the questions. Sorry for the late reply, as I am working on a few deadlines. How about we schedule a time to discuss the items in details later next week?

In the mean time, are you interested in engaging more in the alto effort? For example, we are working on adding more features to the ODL server. Any interest in getting engaged?

Thanks!

Richard

On Thu, Jul 16, 2015 at 2:27 PM, MD I. Islam <mislam4@...> wrote:

I have few questions in mind.

How can we get the dynamic cost map from OpenFlow switch? Do we use OpenFlow meter? Are we considering about dynamic cost-map at all? As there will be multiple competing flows, so available bandwidth will change over time. Please advise.

Can we also create a paradigm to cache contents in the SDN controller (or in a controller app)? I think, this shouldn't be in the context of ALTO, but still would be very helpful. For example, if multiple clients watch a live video on a campus network, we should be able to cache the video slices in the controller. Then controller can push the content proactivly without notifying the clients. Again controller can serve the content in a reactive manner through a north bound protocol.

Today I was trying to write a simple application in ONOS. I was trying the VM from sdnhub. I could run ONOS. The sample Foo program compiled, but I couldn't load it on Karaf. If you have a VM that has the development environment setup, that will be very helpful to start.

Please don't hesitate to let me know if i get anything wrong. Looking forward to your suggestions.

Thanks
Tamim




--
-- 
 =====================================
| Y. Richard Yang <yry@...>   |
| Professor of Computer Science       |
 =====================================




--
-- 
 =====================================
| Y. Richard Yang <yry@...>   |
| Professor of Computer Science       |
 =====================================

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



Re: Few questions on ALTO and ONOS

Y. Richard Yang
 

Dear Tamim,

Wonderful! 

Per my personal wish list, a main feature that I want to improve on is high quality ECS service, based on various metrics. Any interest?

Richard

On Sat, Jul 18, 2015 at 12:35 AM, MD I. Islam <mislam4@...> wrote:
Yeah, sure. I'm interested on adding features to the ALTO ODL server. Please let me know what you want me to do.

Thanks
Tamim

On Fri, Jul 17, 2015 at 12:12 PM, Y. Richard Yang <yry@...> wrote:
Dear Tamim,

Thanks a lot for the questions. Sorry for the late reply, as I am working on a few deadlines. How about we schedule a time to discuss the items in details later next week?

In the mean time, are you interested in engaging more in the alto effort? For example, we are working on adding more features to the ODL server. Any interest in getting engaged?

Thanks!

Richard

On Thu, Jul 16, 2015 at 2:27 PM, MD I. Islam <mislam4@...> wrote:

I have few questions in mind.

How can we get the dynamic cost map from OpenFlow switch? Do we use OpenFlow meter? Are we considering about dynamic cost-map at all? As there will be multiple competing flows, so available bandwidth will change over time. Please advise.

Can we also create a paradigm to cache contents in the SDN controller (or in a controller app)? I think, this shouldn't be in the context of ALTO, but still would be very helpful. For example, if multiple clients watch a live video on a campus network, we should be able to cache the video slices in the controller. Then controller can push the content proactivly without notifying the clients. Again controller can serve the content in a reactive manner through a north bound protocol.

Today I was trying to write a simple application in ONOS. I was trying the VM from sdnhub. I could run ONOS. The sample Foo program compiled, but I couldn't load it on Karaf. If you have a VM that has the development environment setup, that will be very helpful to start.

Please don't hesitate to let me know if i get anything wrong. Looking forward to your suggestions.

Thanks
Tamim




--
-- 
 =====================================
| Y. Richard Yang <yry@...>   |
| Professor of Computer Science       |
 =====================================




--
-- 
 =====================================
| Y. Richard Yang <yry@...>   |
| Professor of Computer Science       |
 =====================================


Re: [release] Autorelease build status

Y. Richard Yang
 

Thanh,

Thanks for the note. We are taking a look at the alto bug.

Thanks!

Richard



On Friday, July 10, 2015, Thanh Ha <thanh.ha@...> wrote:
Hi Everyone,

I'm trying to get autorelease master build working as we haven't had master branch working since Lithium started becoming priority. Another thing we're trying to do is ensure projects are capable of building with JDK8 moving forward so I thought I'd provide periodic status updates to open bugs that we need action on. It's in our best interest to keep autorelease in a working state since the autorelease build does catch build issues that project verify and merge jobs do not catch.

Currently there's 3 open bugs:

alto
simple-impl failing build unable to find controler "sal" artifact [1]

controller
netconf-usermanager fails to build due to missing usermanager [2]

snmp
yang-oid-plugin fails with jdk8 [3]

I hope project leads on these projects can respond and let us know that someone can work on resolving these build related issues.

Regards,

Thanh



--
Richard


Re: ALTO in an SDN environment

Y. Richard Yang
 

Dear Tamim,

Thanks a lot for your note. Our design for ONOS is just getting started. Your question on the specific problems on ONOS is an excellent one, which we have not focused yet. Our initial goal is to design ALTO for both platforms, ODL and ONOS, to achieve a portable design. Your involvement will be great. In which context will you be involved, as an independent open source project, or there is course/research context?

Thanks.

Richard

On Tue, Jul 14, 2015 at 2:04 PM, MD I. Islam <mislam4@...> wrote:
Hi Dr. Yang

I am interested to work on ALTO on ONOS. I'm new to both. Please feel free to direct me to study necessary materials and keep me involved in the discussion and implementation.

Is there an ALTO project for ONOS that I can start playing around? Are we trying to solve any specific problem on ONOS that was not addressed in the ALTO ODL app? It looked like ONOS is a distributed controller, so I guess, that's something new that was not in ODL. Looking forward to your suggestions.

About me: I am a graduate student of Kent State University. I worked as a software engineer for five years. I'm interested to solve practical networking problems using SDN. Please let me know any question.

Thanks
Tamim

On Mon, Jul 13, 2015 at 6:23 PM, Y. Richard Yang <yry@...> wrote:
Dear all,

As IETF'93 is coming soon, it is good time to get some discussion started first so that we may continue at Prague. 

One issue is the relationship between ALTO and SDN. I want to start this thread not only because SDN is a hot topic or ALTO/SDN are two of my main interests recently. More importantly, I feel that a better understanding of ALTO and SDN can help with the future direction of ALTO. This email is not intended to be complete, but more is to get the conversation started.

A good point of the discussion is our experiences in implementing ALTO in OpenDaylight (ODL). A small background digression. A basic version of ALTO has been implemented in the ODL Lithium release. We plan to participate in the next ODL release as well, to add substantial new features, such as incremental updates (Wendy's SSE design), routing state abstraction using declarative equivalence, and automatic map generations. We are also starting the integration of ALTO to ONOS soon. In you are interested in joining such design and development, please let us know. 

Now, what are some key lessons/issues that we have learned in this ALTO/SDN? 

First, a key benefit to ALTO is that it can construct its views from its access to a centralized state of the network provided by SDN. As a basic case, in the current ALTO/ODL implementation, the ALTO server uses l2switch, which is a project in ODL that collects all active endhosts in the network, to construct a dynamic network with two PIDs: internal (for those in the network) and external (for those not). A default cost map is constructed so that  internal <-> external has higher routing costs. As endhosts being collected or pruned from the network state, the ALTO server is notified by ODL's event system automatically, and ALTO's event handler updates the network map automatically. It will be great exercise to push this direction more, for example, by constructing more interesting, network-state maps and endpoint cost services (ECS).

If we say the basic case is what SDN can do for ALTO, the next is what ALTO can do for SDN. In particular, we have extended the path vector proposal substantially to design the new ALTO service called routing state abstraction using declarative equivalence (RSADE); see see http://www.cs.yale.edu/homes/yry/research/TechReports/GWY15.pdf
We feel that the RSADE service will be a very valuable abstraction service for SDN.

Now, some issues and questions that have become more obvious in the process:

- ALTO maps are endhosts based, but SDN allows more fine-grained routing, e.g., routing depending on ports. How do we handle this?

- From the beginning, ALTO's charter limits it to be a network-state-read-only protocol. SDN allows one to "write" a network's state. Suppose we have a general SDN/ALTO environment, for applications such as large-data transfer (e.g., the multi-flow use case, big data), how can such applications use both the ALTO channel and the SDN write channel?

Let me keep this email short and stop here, so that we may have some good discussions, on the mailing list and/or at the Prague meeting.

Cheers,

Richard



 


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





--
-- 
 =====================================
| Y. Richard Yang <yry@...>   |
| Professor of Computer Science       |
 =====================================


Re: ALTO meetings - interactive questions

Y. Richard Yang
 

David,

Sure. I can do 9 am ET Thursday.

Talk to you then.
Richard

On Wed, Jul 15, 2015 at 5:28 AM, David Cosby <dcosby@...> wrote:

Hi Richard,

 

Thank you, we would be very excited to get a few minutes of your time.   I assume you are on ET, so would around 9 AM ET on Thurday AM work for you? 

 

Since I may have a colleague from Beijing join, I was trying to keep the proposed time earlier rather than later.

 

I’ll send along an invite to try to coordinate us.  Please propose some other times of the morning if that won’t work.  We’ll do our best to accommodate your schedule.

 

 

David W. Cosby
Lenovo Researcher
Lenovo Research & Technology
1009 Think Place, Bld 2, 3G17 Morrisville, NC 27560
Lenovo US

Phone919-237-8281
Email919-264-8238
VOIP2978281
Emaildcosby@...

 

Lenovo.com
Twitter | Facebook | Instagram | Blogs | Forums

The-Lenovo-Way

 

 

From: yang.r.yang@... [mailto:yang.r.yang@...] On Behalf Of Y. Richard Yang
Sent: Monday, July 13, 2015 5:17 PM
To: David Cosby
Cc: Jian Li; alto-dev@...; Wendy Roome; Scharf, Michael (Michael)
Subject: Re: ALTO meetings - interactive questions

 

Dear David, Jian,

 

Thank you for looking into ALTO. 

In Lithium, the default costs are set essentially using a binary format. Extending it to improve flexibility is next on our agenda.

 

We are not running weekly meetings in these these few days due to coming IETF. I sure can answer questions. Please pick a time and we can arrange a chat. Morning ET works the best for me.

 

Thanks!

Richard


On Tuesday, July 14, 2015, David Cosby <dcosby@...> wrote:

Hi Richard,

 

Jian and I are looking at Alto on behalf of Lenovo for a project and wanted to consider joining your weekly meetings.  I’m very excited about what I think Alto does.  J

 

I was also hoping there was some chance you might be aware of someone who would be willing to spend about 15 minutes interactively answering questions with us.  I don’t feel experienced enough with Alto yet to feel like I’m making efficient use of the entire team emails, but can do so if/as required.

 

I guess one initial question was how the costs are currently set in Lithium?  We are doing the cost queries in apidoc/explorer and seeing costs that aren’t necessarily obvious.\

 

Thanks,

 

David W. Cosby
Lenovo Researcher
Lenovo Research & Technology
1009 Think Place, Bld 2, 3G17 Morrisville, NC 27560
Lenovo US

Phone919-237-8281
Email919-264-8238
VOIP2978281
Emaildcosby@...

 

Lenovo.com
Twitter | Facebook | Instagram | Blogs | Forums

The-Lenovo-Way

 

 



--
Richard




--
-- 
 =====================================
| Y. Richard Yang <yry@...>   |
| Professor of Computer Science       |
 =====================================


Re: ALTO meetings - interactive questions

David Cosby <dcosby@...>
 

Hi Richard,

 

Thank you, we would be very excited to get a few minutes of your time.   I assume you are on ET, so would around 9 AM ET on Thurday AM work for you? 

 

Since I may have a colleague from Beijing join, I was trying to keep the proposed time earlier rather than later.

 

I’ll send along an invite to try to coordinate us.  Please propose some other times of the morning if that won’t work.  We’ll do our best to accommodate your schedule.

 

 

David W. Cosby
Lenovo Researcher
Lenovo Research & Technology
1009 Think Place, Bld 2, 3G17 Morrisville, NC 27560
Lenovo US

Phone919-237-8281
Email919-264-8238
VOIP2978281
Emaildcosby@...

 

Lenovo.com
Twitter | Facebook | Instagram | Blogs | Forums

The-Lenovo-Way

 

 

From: yang.r.yang@... [mailto:yang.r.yang@...] On Behalf Of Y. Richard Yang
Sent: Monday, July 13, 2015 5:17 PM
To: David Cosby
Cc: Jian Li; alto-dev@...; Wendy Roome; Scharf, Michael (Michael)
Subject: Re: ALTO meetings - interactive questions

 

Dear David, Jian,

 

Thank you for looking into ALTO. 

In Lithium, the default costs are set essentially using a binary format. Extending it to improve flexibility is next on our agenda.

 

We are not running weekly meetings in these these few days due to coming IETF. I sure can answer questions. Please pick a time and we can arrange a chat. Morning ET works the best for me.

 

Thanks!

Richard


On Tuesday, July 14, 2015, David Cosby <dcosby@...> wrote:

Hi Richard,

 

Jian and I are looking at Alto on behalf of Lenovo for a project and wanted to consider joining your weekly meetings.  I’m very excited about what I think Alto does.  J

 

I was also hoping there was some chance you might be aware of someone who would be willing to spend about 15 minutes interactively answering questions with us.  I don’t feel experienced enough with Alto yet to feel like I’m making efficient use of the entire team emails, but can do so if/as required.

 

I guess one initial question was how the costs are currently set in Lithium?  We are doing the cost queries in apidoc/explorer and seeing costs that aren’t necessarily obvious.\

 

Thanks,

 

David W. Cosby
Lenovo Researcher
Lenovo Research & Technology
1009 Think Place, Bld 2, 3G17 Morrisville, NC 27560
Lenovo US

Phone919-237-8281
Email919-264-8238
VOIP2978281
Emaildcosby@...

 

Lenovo.com
Twitter | Facebook | Instagram | Blogs | Forums

The-Lenovo-Way

 

 



--
Richard


Re: ALTO in an SDN environment

Y. Richard Yang
 

I was asked to elaborate a bit more on the paragraph below. So here it is.  

On Tue, Jul 14, 2015 at 6:23 AM, Y. Richard Yang <yry@...> wrote:
- From the beginning, ALTO's charter limits it to be a network-state-read-only protocol. SDN allows one to "write" a network's state. Suppose we have a general SDN/ALTO environment, for applications such as large-data transfer (e.g., the multi-flow use case, big data), how can such applications use both the ALTO channel and the SDN write channel?

Imagine a centralized control plane that can coordinate the data transfers. Applying divide-and-conquer, we can see three key modules:

M1: Endpoint (resource) selection: A receiver may have a set of candidate senders and can choose one (or multiple and then conduct reassembly);  A sender may have multiple receivers to choose from as well.

M2: Routing: Given a sender and a receiver, what is the path (or are the paths) of the packets from the sender to the receiver?

M3: Rate allocation: What is the transmission rate from a sender to a receiver? We assume no multicast.

To see how each module is implemented by network and/or by application, consider what is network state. In a current, typical OF setting, the network switches will have flow tables and ovsdb, which implement routing (M2) and queueing (M3). Hence, we have the following implementation options:
M1: app
M2: net
M3: app and/or net
 
So far, the main focus of ALTO is on providing info from network to app for the app to implement M1. The recent effort on path vector starts to help providing  info from network to app for the app to implement M3. 

Now, suppose SDN becomes widely used, and hence app may have an (north-bound) API to influence M2 (e.g., a first API might be PCEP like API). This will create control feedback, and hence a key issue for ALTO then is what the interactions might look like. IETF does not define algorithms but can provide guidance on the architecture.

Cheers,
Richard


Re: [alto] ALTO in an SDN environment

xinwang
 

Hi all,

I am quite interested in the second one that how the application influences ALTO through SDN. Assume that there are several paths for data transfer computed initially at SDN controller, and path can not be set anymore after even the network becomes congested. Then applications decide how to schedule data transfer along these paths. When the result computed by applications submitted to SDN controller, the controller sets rules for these flows. Finally, ALTO server collects the current network state, and finds the cost has been updated.

However, it would become complex when the SDN controller can set new paths for applications requirements. The controller can move the data flows from the original path to the new one, or only makes new data flows transmit through new paths. Both would affect the cost in ALTO server. 

I would like to focus on this problem these days.

Xin

On Jul 14, 2015, at 6:23 AM, Y. Richard Yang <yry@...> wrote:

Dear all,

As IETF'93 is coming soon, it is good time to get some discussion started first so that we may continue at Prague. 

One issue is the relationship between ALTO and SDN. I want to start this thread not only because SDN is a hot topic or ALTO/SDN are two of my main interests recently. More importantly, I feel that a better understanding of ALTO and SDN can help with the future direction of ALTO. This email is not intended to be complete, but more is to get the conversation started.

A good point of the discussion is our experiences in implementing ALTO in OpenDaylight (ODL). A small background digression. A basic version of ALTO has been implemented in the ODL Lithium release. We plan to participate in the next ODL release as well, to add substantial new features, such as incremental updates (Wendy's SSE design), routing state abstraction using declarative equivalence, and automatic map generations. We are also starting the integration of ALTO to ONOS soon. In you are interested in joining such design and development, please let us know. 

Now, what are some key lessons/issues that we have learned in this ALTO/SDN? 

First, a key benefit to ALTO is that it can construct its views from its access to a centralized state of the network provided by SDN. As a basic case, in the current ALTO/ODL implementation, the ALTO server uses l2switch, which is a project in ODL that collects all active endhosts in the network, to construct a dynamic network with two PIDs: internal (for those in the network) and external (for those not). A default cost map is constructed so that  internal <-> external has higher routing costs. As endhosts being collected or pruned from the network state, the ALTO server is notified by ODL's event system automatically, and ALTO's event handler updates the network map automatically. It will be great exercise to push this direction more, for example, by constructing more interesting, network-state maps and endpoint cost services (ECS).

If we say the basic case is what SDN can do for ALTO, the next is what ALTO can do for SDN. In particular, we have extended the path vector proposal substantially to design the new ALTO service called routing state abstraction using declarative equivalence (RSADE); see see http://www.cs.yale.edu/homes/yry/research/TechReports/GWY15.pdf
We feel that the RSADE service will be a very valuable abstraction service for SDN.

Now, some issues and questions that have become more obvious in the process:

- ALTO maps are endhosts based, but SDN allows more fine-grained routing, e.g., routing depending on ports. How do we handle this?

- From the beginning, ALTO's charter limits it to be a network-state-read-only protocol. SDN allows one to "write" a network's state. Suppose we have a general SDN/ALTO environment, for applications such as large-data transfer (e.g., the multi-flow use case, big data), how can such applications use both the ALTO channel and the SDN write channel?

Let me keep this email short and stop here, so that we may have some good discussions, on the mailing list and/or at the Prague meeting.

Cheers,

Richard



 

_______________________________________________
alto mailing list
alto@...
https://www.ietf.org/mailman/listinfo/alto


ALTO in an SDN environment

Y. Richard Yang
 

Dear all,

As IETF'93 is coming soon, it is good time to get some discussion started first so that we may continue at Prague. 

One issue is the relationship between ALTO and SDN. I want to start this thread not only because SDN is a hot topic or ALTO/SDN are two of my main interests recently. More importantly, I feel that a better understanding of ALTO and SDN can help with the future direction of ALTO. This email is not intended to be complete, but more is to get the conversation started.

A good point of the discussion is our experiences in implementing ALTO in OpenDaylight (ODL). A small background digression. A basic version of ALTO has been implemented in the ODL Lithium release. We plan to participate in the next ODL release as well, to add substantial new features, such as incremental updates (Wendy's SSE design), routing state abstraction using declarative equivalence, and automatic map generations. We are also starting the integration of ALTO to ONOS soon. In you are interested in joining such design and development, please let us know. 

Now, what are some key lessons/issues that we have learned in this ALTO/SDN? 

First, a key benefit to ALTO is that it can construct its views from its access to a centralized state of the network provided by SDN. As a basic case, in the current ALTO/ODL implementation, the ALTO server uses l2switch, which is a project in ODL that collects all active endhosts in the network, to construct a dynamic network with two PIDs: internal (for those in the network) and external (for those not). A default cost map is constructed so that  internal <-> external has higher routing costs. As endhosts being collected or pruned from the network state, the ALTO server is notified by ODL's event system automatically, and ALTO's event handler updates the network map automatically. It will be great exercise to push this direction more, for example, by constructing more interesting, network-state maps and endpoint cost services (ECS).

If we say the basic case is what SDN can do for ALTO, the next is what ALTO can do for SDN. In particular, we have extended the path vector proposal substantially to design the new ALTO service called routing state abstraction using declarative equivalence (RSADE); see see http://www.cs.yale.edu/homes/yry/research/TechReports/GWY15.pdf
We feel that the RSADE service will be a very valuable abstraction service for SDN.

Now, some issues and questions that have become more obvious in the process:

- ALTO maps are endhosts based, but SDN allows more fine-grained routing, e.g., routing depending on ports. How do we handle this?

- From the beginning, ALTO's charter limits it to be a network-state-read-only protocol. SDN allows one to "write" a network's state. Suppose we have a general SDN/ALTO environment, for applications such as large-data transfer (e.g., the multi-flow use case, big data), how can such applications use both the ALTO channel and the SDN write channel?

Let me keep this email short and stop here, so that we may have some good discussions, on the mailing list and/or at the Prague meeting.

Cheers,

Richard



 


Re: ALTO meetings - interactive questions

Y. Richard Yang
 

Dear David, Jian,

Thank you for looking into ALTO. 

In Lithium, the default costs are set essentially using a binary format. Extending it to improve flexibility is next on our agenda.

We are not running weekly meetings in these these few days due to coming IETF. I sure can answer questions. Please pick a time and we can arrange a chat. Morning ET works the best for me.

Thanks!
Richard

On Tuesday, July 14, 2015, David Cosby <dcosby@...> wrote:

Hi Richard,

 

Jian and I are looking at Alto on behalf of Lenovo for a project and wanted to consider joining your weekly meetings.  I’m very excited about what I think Alto does.  J

 

I was also hoping there was some chance you might be aware of someone who would be willing to spend about 15 minutes interactively answering questions with us.  I don’t feel experienced enough with Alto yet to feel like I’m making efficient use of the entire team emails, but can do so if/as required.

 

I guess one initial question was how the costs are currently set in Lithium?  We are doing the cost queries in apidoc/explorer and seeing costs that aren’t necessarily obvious.\

 

Thanks,

 

David W. Cosby
Lenovo Researcher
Lenovo Research & Technology
1009 Think Place, Bld 2, 3G17 Morrisville, NC 27560
Lenovo US

Phone919-237-8281
Email919-264-8238
VOIP2978281
Emaildcosby@...

 

Lenovo.com
Twitter | Facebook | Instagram | Blogs | Forums

The-Lenovo-Way

 

 



--
Richard


Some ideas about the interop day

Jensen <2010_fno@...>
 

Dear Richard,

For my understanding, we need also plan for some details beyond how to set up the tests.

There are some ideas about the interop day:

1) We can build a web UI for presentation and visualizing the results of tests.
2) We can send out a welcome mail to others, and who want to participate the interop day can confirm this mail.
3) Shall we build a simple web site to introduce the day (The schedule and an abstract)?
...

I don't know whether these suggestions are helpful and whether these are you want. Please correct me if I have misunderstood anything.

Thanks,

--
Jensen Zhang
Tongji University


Re: [nets] ALTO IETF'93 (Prague) interop planning

"Huaming <guo522@...>
 

Hi all,

I would like to do some.

------------------
Best!

Huaming
 


------------------ Original ------------------
From:  "Jensen";<2010_fno@...>;
Date:  Tue, Jul 7, 2015 11:31 PM
To:  "Y. Richard Yang"<yry@...>;
Cc:  "nets@..."<nets@...>; "Wendy Roome"<wendy@...>; "Jan Seedorf"<Jan.Seedorf@...>; "alto-dev@..."<alto-dev@...>; "Sabine Randriamasy"<Sabine.Randriamasy@...>; "Gurbani, Vijay K (Vijay)"<vijay.gurbani@...>;
Subject:  Re: [nets] ALTO IETF'93 (Prague) interop planning

Dear Richard,

I can do something about Task1. Since I have not much experience in ALTO programming, I hope some one(s) with more experience can work together with me.

And about Task2, I don't learn about the details of interop, so I can't give any suggestions now.

Thanks,
Jensen

-----Original Messages-----
From: "Y. Richard Yang" <yry@...>
Sent Time: 2015-07-07 12:27:24 (Tuesday)
To: "Wendy Roome" <wendy@...>, "nets@..." <nets@...>, "alto-dev@..." <alto-dev@...>, "Sabine Randriamasy" <Sabine.Randriamasy@...>, "Gurbani, Vijay K (Vijay)" <vijay.gurbani@...>, "Jan Seedorf" <Jan.Seedorf@...>
Cc:
Subject: [nets] ALTO IETF'93 (Prague) interop planning

Dear all,

Sorry for the spamming. If ALTO is not your current focus, please skip this email thread :-)

As July 20 will come in fast (exactly two weeks from today), I feel that it is time for our team to get the preparation fully started. After some brief preparation internally, we can engage on the ALTO mailing list and try to engage more broadly.

First, the basic info:

Time: ** MONDAY, July 20th, 20:00-23:00 **

Key draft guiding the interop:
https://datatracker.ietf.org/doc/draft-roome-alto-interop-ietf93/

Specific tasks:

T1: Pre-testing the interop draft (Wendy has some initial tests already.) Can some of us do a test using the ODL server? Volunteers? If no volunteer(s) by tomorrow, I will pick.

T2: Planning the details of interop day (July 20). Any volunteers?

What else do we want to achieve/test during the interop?

Thanks a lot!

Richard


--
Jensen Zhang
Tongji University


Re: [nets] ALTO IETF'93 (Prague) interop planning

Jan Seedorf <Jan.Seedorf@...>
 

Dear Jensen,

 

the details of the interop are pretty much up to you guys, i.e. the implementers taking part in the interop. We (the chairs) organized a room (3 hours on Monday evening), and what Richard is saying (and I totally agree) is that it is a good idea to start thinking now what a “detailed” plan could look like, in order to make the best use of the time. So any ideas / thoughts are welcome.

 

-          Jan

 

From: Jensen [mailto:2010_fno@...]
Sent: Dienstag, 7.
Juli 2015 17:31
To: Y. Richard Yang
Cc: Wendy Roome; nets@...; alto-dev@...; Sabine Randriamasy; Gurbani, Vijay K (Vijay); Jan Seedorf
Subject: Re: [nets] ALTO IETF'93 (Prague) interop planning

 

Dear Richard,

I can do something about Task1. Since I have not much experience in ALTO programming, I hope some one(s) with more experience can work together with me.

And about Task2, I don't learn about the details of interop, so I can't give any suggestions now.

Thanks,
Jensen


-----Original Messages-----
From: "Y. Richard Yang" <
yry@...>
Sent Time: 2015-07-07 12:27:24 (Tuesday)
To: "Wendy Roome" <
wendy@...>, "nets@..." <nets@...>, "alto-dev@..." <alto-dev@...>, "Sabine Randriamasy" <Sabine.Randriamasy@...>, "Gurbani, Vijay K (Vijay)" <vijay.gurbani@...>, "Jan Seedorf" <Jan.Seedorf@...>
Cc:
Subject: [nets] ALTO IETF'93 (Prague) interop planning

Dear all,

 

Sorry for the spamming. If ALTO is not your current focus, please skip this email thread :-)

 

As July 20 will come in fast (exactly two weeks from today), I feel that it is time for our team to get the preparation fully started. After some brief preparation internally, we can engage on the ALTO mailing list and try to engage more broadly.

 

First, the basic info:


Time: ** MONDAY, July 20th, 20:00-23:00 **

 

Key draft guiding the interop: 
https://datatracker.ietf.org/doc/draft-roome-alto-interop-ietf93/

 

Specific tasks:

 

T1: Pre-testing the interop draft (Wendy has some initial tests already.) Can some of us do a test using the ODL server? Volunteers? If no volunteer(s) by tomorrow, I will pick.

 

T2: Planning the details of interop day (July 20). Any volunteers?

 

What else do we want to achieve/test during the interop?

 

Thanks a lot!

 

Richard



--
Jensen Zhang
Tongji University


Re: ALTO IETF'93 (Prague) interop planning

Jan Seedorf <Jan.Seedorf@...>
 

Hi Richard,

 

thanks a lot for starting this discussion and taking the lead in organizing the interop!

 

-          Jan

 

From: yang.r.yang@... [mailto:yang.r.yang@...] On Behalf Of Y. Richard Yang
Sent: Dienstag, 7. Juli 2015 06:27
To: Wendy Roome; nets@...; alto-dev@...; Sabine Randriamasy; Gurbani, Vijay K (Vijay); Jan Seedorf
Subject: ALTO IETF'93 (Prague) interop planning

 

Dear all,

 

Sorry for the spamming. If ALTO is not your current focus, please skip this email thread :-)

 

As July 20 will come in fast (exactly two weeks from today), I feel that it is time for our team to get the preparation fully started. After some brief preparation internally, we can engage on the ALTO mailing list and try to engage more broadly.

 

First, the basic info:


Time: ** MONDAY, July 20th, 20:00-23:00 **

 

Key draft guiding the interop: 
https://datatracker.ietf.org/doc/draft-roome-alto-interop-ietf93/

 

Specific tasks:

 

T1: Pre-testing the interop draft (Wendy has some initial tests already.) Can some of us do a test using the ODL server? Volunteers? If no volunteer(s) by tomorrow, I will pick.

 

T2: Planning the details of interop day (July 20). Any volunteers?

 

What else do we want to achieve/test during the interop?

 

Thanks a lot!

 

Richard


Re: [nets] ALTO IETF'93 (Prague) interop planning

Jensen <2010_fno@...>
 

Dear Richard,

I can do something about Task1. Since I have not much experience in ALTO programming, I hope some one(s) with more experience can work together with me.

And about Task2, I don't learn about the details of interop, so I can't give any suggestions now.

Thanks,
Jensen

-----Original Messages-----
From: "Y. Richard Yang" <yry@...>
Sent Time: 2015-07-07 12:27:24 (Tuesday)
To: "Wendy Roome" <wendy@...>, "nets@..." <nets@...>, "alto-dev@..." <alto-dev@...>, "Sabine Randriamasy" <Sabine.Randriamasy@...>, "Gurbani, Vijay K (Vijay)" <vijay.gurbani@...>, "Jan Seedorf" <Jan.Seedorf@...>
Cc:
Subject: [nets] ALTO IETF'93 (Prague) interop planning

Dear all,

Sorry for the spamming. If ALTO is not your current focus, please skip this email thread :-)

As July 20 will come in fast (exactly two weeks from today), I feel that it is time for our team to get the preparation fully started. After some brief preparation internally, we can engage on the ALTO mailing list and try to engage more broadly.

First, the basic info:

Time: ** MONDAY, July 20th, 20:00-23:00 **

Key draft guiding the interop: 
https://datatracker.ietf.org/doc/draft-roome-alto-interop-ietf93/

Specific tasks:

T1: Pre-testing the interop draft (Wendy has some initial tests already.) Can some of us do a test using the ODL server? Volunteers? If no volunteer(s) by tomorrow, I will pick.

T2: Planning the details of interop day (July 20). Any volunteers?

What else do we want to achieve/test during the interop?

Thanks a lot!

Richard


--
Jensen Zhang
Tongji University


ALTO IETF'93 (Prague) interop planning

Y. Richard Yang
 

Dear all,

Sorry for the spamming. If ALTO is not your current focus, please skip this email thread :-)

As July 20 will come in fast (exactly two weeks from today), I feel that it is time for our team to get the preparation fully started. After some brief preparation internally, we can engage on the ALTO mailing list and try to engage more broadly.

First, the basic info:

Time: ** MONDAY, July 20th, 20:00-23:00 **

Key draft guiding the interop: 
https://datatracker.ietf.org/doc/draft-roome-alto-interop-ietf93/

Specific tasks:

T1: Pre-testing the interop draft (Wendy has some initial tests already.) Can some of us do a test using the ODL server? Volunteers? If no volunteer(s) by tomorrow, I will pick.

T2: Planning the details of interop day (July 20). Any volunteers?

What else do we want to achieve/test during the interop?

Thanks a lot!

Richard


Re: [alto]Protocol between alto server and information sources

Gao Kai
 

Hi Richard,

Thanks for your comments.

The reason I think a standard might be helpful is exactly that an implementation can then get information from different sources without worrying about adaption issues.  I think such a standard, which decouples the development of ALTO servers and information sources, would be beneficial in the long run.


But private protocols can still exist for certain implementations.   Actually they can easily extend the protocol by replacing 'type' and 'source' with some private values and filling the 'data' field in their own format.

Regards,
Kai

On 03/07/15 09:55, Y. Richard Yang wrote:
Dear Kai,

Thanks for the proposal. Here is some initial feedback.

Please see below.


On Thu, Jul 2, 2015 at 12:26 AM, Gao Kai <gaok12@...> wrote:
Hi all,

I have some thoughts on the implementation of ALTO servers and I'd like to get some feedback on the idea.

The basic functionalities of an ALTO server are:

- Collecting data from the information sources;
- Publishing the information to clients (using ALTO protocol).

While the latter is well-defined in RFC 7285, there are no standards for the communication between an ALTO server and information sources.  There are three scenarios:

- The ALTO server is deeply embedded into the information source, just like what we are trying to do in Open Daylight.

- The ALTO server is partially embedded into the information source.  For example, in the early stage of out implementation in ODL, we used an external server which pulls data from ODL using RESTCONF and converts them into RFC7285-compatible formats.

- The ALTO server is decoupled from the information source.

It is for the last scenario that a standard protocol might be helpful. 

Provisioning of ALTO information is not defined in the ALTO protocol. In a totally private setting, the protocol and tool for an ALTO server to access/control each information source and pull related info from the source (or the source pushes related info to an ALTO server) can be totally private, and hence there is not a need to define a standard. 

I agree that in a more general setting, an ALTO server may use multiple information sources, and the sources may use different tools and belong to different domains. 

Here is a problem that I am thinking of how to solve: how to implement the endpoint cost service? This depends on the scenarios, as you identified. For example, here are two scenarios:

- All endpoints and the network connecting them belong to the same SDN controller. The ALTO server can use the state and control functions available in the SDN controller to obtain the info.

- It is not an SDN setting. Rather, assume a Science Network setting.  A tool comes to mind is perfSonar (https://fasterdata.es.net/performance-testing/perfsonar/), which is an infrastructure used in Science Networks to measure loss and bw results. The ALTO server may use the data from perfSonar (or even control on-demand measurement) to get the results (it may need to use the perfsonar hosts as landmark...)
 
I believe that the preceding will be the main complexity and value of providing ALTO. My understanding is that you want to introduce a standard here, so that an ALTO server can use a uniform interface to use multiple information sources (i.e., the ALTO server does not need to write a lot of adaptation code, each for query ODL, one for query ONOS, one for query PerfSonar, ...)?

Do I understand your intention?

Richard


To get started, I can think of two basic and probably most common implementation choices, and they both can have multiple different information sources:

- End-to-End:
  The server builds its maps using an full-mesh internal representation.  This can happen if the server is using end-to-end measurement methods or it just doesn't have the priority to fetch topology information.

- Topology-based:
  In this case the server is using a graph representation and there can be some internal nodes besides endpoints.  A server can fetch topology view directly, either from configurations or by making a query to a SDN controller.  Also one can use aggregated data such as the inferred AS graph.

Accordingly we can identify the following kinds of information for both implementation choices:

- Connection-based statistics;
- Link-based statistics;
- (?) Node-based statistics.

All three statistics can be encapsulated using the following JSON representation:

    {
        /* the type of the statistics */
        'type': 'alto-IS-e2e',
        /* choices: alto-IS-e2e, alto-IS-link, alto-IS-node, etc. */

        /* identity for the provider of the information */
        'source': 'grid-ftp-client:ef423dab',

        'data': [
            {
                'meta': {
                    /* e2e */
                    'src': 'ipv4:X.X.X.X',
                    'dst': 'ipv4:Y.Y.Y.Y',

                    /* link */
                    'id': 'e15',

                    /* node */
                    'id': 'n02'
                },
                'statistics': [
                    /* e2e */
                    'average-round-trip-time': '10ms',
                    'average-drop-rate-percentage': '5',
                    ...,

                    /* link */
                    'status': 'up',
                    'capacity': '10Gbps',
                    'available-bandwidth': '5Gbps',
                    ...,

                    /* node */
                    ...
                    /* actually I don't have any statistics for nodes in mind */
                ]
            },
            ...
        ]
    }

There are also considerations on push/pull modes, integration to IRD and potential DDoS threats but I'd like to hear some feedback on the proposal from you alto guys.

Thanks!

Regards,
Kai


Intent to participate in Beryllium Release - ALTO

Y. Richard Yang
 

Hi,

The ALTO project formally joins the OpenDaylight Beryllium Simultaneous Release and agrees to the activities and timeline documented on the Beryllium Release Plan Page.

 

Regards,

Richard


Re: Task Assignments

dongshu
 

No worries. Take care and have a good rest!

On Wed, Jun 24, 2015 at 3:07 PM, <92yichenqian@...> wrote:

Hi all,

Sorry for missing the meeting today. I went to the hospital yesterday to extract a tooth. Unfortunatly i met some problems to stop bleeding. It stuck me so i didn't check my email yesterday. I had a rest this morning to make sure it doesn't bleed and just saw the emails.

Sorry,
Yichen


-----原始邮件-----
发件人: "Shu Dong" <dongs2011@...>
发送时间: 2015-06-24 12:07:47 (星期三)
收件人: alto-dev@..., "Richard Yang" <yry@...>, "Kai GAO" <godrickk@...>, wangxin <xinwang2014@...>, "Xiao Lin (Tongji)" <378633397@...>, "王君卓" <wangjunzhuo200@...>, "张静轩" <2010_fno@...>
抄送:
主题: [alto-dev] Task Assignments


Hi all,

Since @Kai will figure out how to turn sonar on this afternoon, the others in Tongji will focus on adding more unit tests. Here is task assignments for alto members in Tongji:

1. @Jenson and @Linxiao will be responsible for adding unit tests for alto-commons and alto-extensions.
2. @Dongshu will be in charge of updating the release review and notes page and adding unit tests for alto-manager
3. @Xin wang will be responsible for adding unit tests of alto-provider and alto-hosttracker.
4. I will assgin tasks to @junzhuo once he reached the lab.

@kai Since alto-service and alto-northbound are your projects, do you want to shift some work to others or you will add unit tests for this two by yourself? 

Thanks.

From,
Shu Dong



Re: Task Assignments

Yichen Qian
 

Hi all,

Sorry for missing the meeting today. I went to the hospital yesterday to extract a tooth. Unfortunatly i met some problems to stop bleeding. It stuck me so i didn't check my email yesterday. I had a rest this morning to make sure it doesn't bleed and just saw the emails.

Sorry,
Yichen


-----原始邮件-----
发件人: "Shu Dong" <dongs2011@...>
发送时间: 2015-06-24 12:07:47 (星期三)
收件人: alto-dev@..., "Richard Yang" <yry@...>, "Kai GAO" <godrickk@...>, wangxin <xinwang2014@...>, "Xiao Lin (Tongji)" <378633397@...>, "王君卓" <wangjunzhuo200@...>, "张静轩" <2010_fno@...>
抄送:
主题: [alto-dev] Task Assignments

Hi all,

Since @Kai will figure out how to turn sonar on this afternoon, the others in Tongji will focus on adding more unit tests. Here is task assignments for alto members in Tongji:

1. @Jenson and @Linxiao will be responsible for adding unit tests for alto-commons and alto-extensions.
2. @Dongshu will be in charge of updating the release review and notes page and adding unit tests for alto-manager
3. @Xin wang will be responsible for adding unit tests of alto-provider and alto-hosttracker.
4. I will assgin tasks to @junzhuo once he reached the lab.

@kai Since alto-service and alto-northbound are your projects, do you want to shift some work to others or you will add unit tests for this two by yourself? 

Thanks.

From,
Shu Dong

381 - 400 of 542