Shu and I attended the review meeting last night, and the full log of the meeting is attached. Just for reference :)

Jensen Zhang
Tongji University

2015-06-23 17:24 GMT+08:00 Shu Dong <dongs2011@...>:

It should be 11:10 PM CT. Typo : ) 

On Tue, Jun 23, 2015 at 5:23 PM, Shu Dong <dongs2011@...> wrote:

According to this spreadsheet https://docs.google.com/spreadsheets/d/1PYxjiSYEks44uJByVO1P44rnI5xTJRulpKyrSsDQF9g/edit#gid=743945554, the meeting for Alto is at 8:10 AM PDT tomorrow, which is 11:30 PM CT. It will be great if we could bring sonar and jenkins on before tomorrow night.

On Tue, Jun 23, 2015 at 4:53 PM, Gao Kai <godrickk@...> wrote:

What is the due date? I made a little investigation into sonar and jenkins and if time permits we can put some effort into brining them on.

However I think ODL is using sonar and jenkins so it is possible that we only need to improve the unit tests.

On 23/06/15 15:40, Shu Dong wrote:

@Kai That would be great!

Also, I saw that most of other projects are using Sonar or Jenkins Coverage Report(see the links attached in quality assurance section of the release review wiki page) to track the unit test coverage. I have not figure out how it works but I believe we should switch to these two platforms as well(or we already have? Correct me here if necessary).

Thanks!

​

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

-----原始邮件-----
发件人: "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

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

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 919-237-8281 919-264-8238 2978281 dcosby@...   Lenovo.com Twitter | Facebook | Instagram | Blogs | Forums

 

 

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

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

[1] https://bugs.opendaylight.org/show_bug.cgi?id=3955

[2] https://bugs.opendaylight.org/show_bug.cgi?id=3963

[3] https://bugs.opendaylight.org/show_bug.cgi?id=3953