z.archive.alto-dev@lists.opendaylight.org | [alto] ALTO implementation interoperability

Y. Richard Yang

Dear Christian,

It is great to hear about your development. Regarding open source implementation, some of us are developing an open source ALTO server in OpenDayLight. We are slightly behind the schedule of the Lithium Release, but are making good progress lately. The yang model can be found from the ODL alto project git. It is great to hear about your interest in the client side. We are developing a client in a science network setting (to work with GridFTP). We will be happy to share, if interested.

Thanks!

Richard

Show quoted text

On Monday, April 6, 2015, Christian Esteve Rothenberg <chesteve@...> wrote:

Hi all,

we at University of Campinas are developing an ALTO server
implementation (for IXP-related use cases) based on Neo4j graph DB and
Open Daylight for a subset of ALTO services and would like to know
about related open source mplementation work, both at the server side
but mostly interested in the client side for interop testing and
further use case developments.

Looking forward to hear more about the Prague IETF opportunities for
ALTO interop (Raphael, please add to your agenda).

Thx,
Christian

From: Jan Seedorf <Jan.Seedorf at neclab.eu>
To: "Y. Richard Yang" <yry at cs.yale.edu>, Hans Seidel <hseidel at benocs.com>
Cc: IETF ALTO <alto at ietf.org>
Date: Fri, 20 Mar 2015 14:41:12 +0000
In-reply-to: <CANUuoLo-uVXoJuoHDpaZjEOEfihxMc0G6oYZOvrpPhCP_8G1mw@...>
References: <5507EDC7.8060607@...>
<55081EFD.3040004@...>
<CANUuoLrAq2652MywG43iDWtzP4QikrYBw7N_-wg4MXOefd0Upw@...>
<550AA9D6.908@...>
<CANUuoLo-uVXoJuoHDpaZjEOEfihxMc0G6oYZOvrpPhCP_8G1mw@...>

________________________________

We have also put this topic on the chair slides for the session in
Dallas to get feedback from the room, but please also continue raising
your opinion on this here on the ML.

- Jan

From: alto [mailto:alto-bounces at ietf.org] On Behalf Of Y. Richard Yang
Sent: Donnerstag, 19. März 2015 22:26
To: Hans Seidel
Cc: IETF ALTO
Subject: Re: [alto] ALTO implementation interoperability

Hi Hans,

On Thu, Mar 19, 2015 at 6:49 AM, Hans Seidel <hseidel at benocs.com> wrote:

It will be cool to have an interop for the summer IETF. For those who
are interested, some of us are working on having an open-source ALTO
server running in ODL. We are slightly behind schedule, but should be
able to catch up in Apr., after IETF. If there is anyone who is
interested in collaboration, you are more than welcome.

I also like the idea of an interop for the summer IETF in Prague.
Since I am rather new to the IETF community, I am not very familiar
with the procedures but if I can be of any help, let me know.

Wonderful! Some of us here will want to engage in the development of
an interop in Prague as well. It will be nice to coordinate and get
started soon, say after this IETF.

Thanks!

Richard

Hans

Richard

Cheers,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani at alcatel-lucent.com
Web: https://urldefense.proofpoint.com/v2/url?u=http-3A__ect.bell-2Dlabs.com_who_vkg_&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=IFXVSS1Ngo0C7z51Gunp5gTAVG7hdQAOfiXLLRkPLi4&s=RUjSP5rpFsp8V2Y0xuG9_3pFcAAsDEjzi2YQNNaMKfY&e=
| Calendar:https://urldefense.proofpoint.com/v2/url?u=http-3A__goo.gl_x3Ogq&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=IFXVSS1Ngo0C7z51Gunp5gTAVG7hdQAOfiXLLRkPLi4&s=wY56fXByx0Kd3boQqPHpBjX7uzem5fDJHZAW1FIv_Mc&e=
_______________________________________________
alto mailing list
alto at ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=IFXVSS1Ngo0C7z51Gunp5gTAVG7hdQAOfiXLLRkPLi4&s=JAiHH7palOiAkB3m6zdiENhShLMINWuIhPrijAeT0iQ&e=

--

BENOCS GmbH

Dipl.-Ing. Hans Seidel

Winterfeldtstr. 21

10781 Berlin

Germany

Phone: +49 - 30 / 577 0004-0

Email: hans.seidel at benocs.com

www.benocs.com

Board of Management:

Michael Wolz, Dr.-Ing. Oliver Holschke, Dr.-Ing. Ingmar Poese

Commercial Register: Amtsgericht Bonn HRB 19378

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

--
Richard

Wendy Roome

#9

Questions for those interested in an ALTO interop test ….

1. RFC 7285 allows a server to present multiple Network Maps, but does not require a server to support them. But it would simplify the tests if we could assume all servers can be configured to present an IRD with more than one Network Map. Otherwise we will need different test setups, and two different classes of servers.

So would anyone object to requiring servers to present multiple Network Maps?

2. Clients should be able to cope with an IRD with multiple Network Maps, but the RFC does not require them to be able to use anything other than the default network.One way to handle that is to define two sets of client tests: one which uses the default network map (and requires the client to use the cost maps for the default map, rather than a cost map for a different network), and an optional set that uses a secondary network map.

3. The RFC allows IRD chaining — a root IRD can reference secondary IRDs with additional resources. Should we require servers to support that feature?

- Wendy Roome

Y. Richard Yang

#10

Wendy,

On Monday, April 6, 2015, Wendy Roome <wendy@...> wrote:

Questions for those interested in an ALTO interop test ….

1. RFC 7285 allows a server to present multiple Network Maps, but does not require a server to support them. But it would simplify the tests if we could assume all servers can be configured to present an IRD with more than one Network Map. Otherwise we will need different test setups, and two different classes of servers.

So would anyone object to requiring servers to present multiple Network Maps?

I have no problem with this requirement.

2. Clients should be able to cope with an IRD with multiple Network Maps, but the RFC does not require them to be able to use anything other than the default network.One way to handle that is to define two sets of client tests: one which uses the default network map (and requires the client to use the cost maps for the default map, rather than a cost map for a different network), and an optional set that uses a secondary network map.

This setting is also fine with me.

3. The RFC allows IRD chaining — a root IRD can reference secondary IRDs with additional resources. Should we require servers to support that feature?

Do you mean that the server root IRD must include at least an IRD resource? I feel that this should be optional. If really required, I assume that the server can post a second level IRD that points to a subset at the same server, unless we want to test a case of using IRD chaining to use different ALTO servers.

Richard

- Wendy Roome

--
Richard

Y. Richard Yang

#79

A good starting point. I added the alto-dev mailing list on opendaylight. The team there has test cases to test the correctness of their alto server in ODL.

Richard

Show quoted text

On Tuesday, May 12, 2015, Huaming Guo郭华明 <guohuaming@...> wrote:

Hi Wendy, all,

I think we can first go through a list of all test cases, then we complete all details.

I post the list below. The cases with * are added or updated by me. I also like to

serve an editor, if possible.

1. Information Resource Directory

1.1 Test-IRD-1: The Information Resource Directory (IRD) enumerates URIs

at which an ALTO server offers Information Resources.

*1.2 Test-IRD-2 ALTO server delegate IRD to a subdomain.

2. Map Service

2.1 Test-MAPS-1: An ALTO client retrieves a complete network map.

2.2 Test-MAPS-2: An ALTO client retrieves a complete cost map for the

numerical cost mode.

2.3 Test-MAPS-3: An ALTO client retrieves a complete cost map for the

ordinal cost mode.

2.4 Test-MAPS-4: This test is designed to detect a change in the

network map.

3. Map-Filtering Service

*3.1 Test-FILTER-1: An ALTO client sends a request to get a filtered network map

of PID mypid2.

*3.2 Test-FILTER-2: An ALTO client sends a request to get a filtered cost map

from a source PID to a set of destination PIDs.

*3.3 Test-FILTER-3: An ALTO client requests the cost map subject to

certain constraints.

4. Endpoint Property Service

4.1 Test-EPS-1: An ALTO client retrieves a PID for IPv4 address

192.168.1.23.

4.2 Test-EPS-2: An ALTO client retrieves a PID for IPv4 address

192.168.10.23.

4.3 Test-EPS-3: An ALTO client retrieves a PID for IPv4 address

201.1.13.12.

4.4 Test-EPS-4: An ALTO client retrieves a PID for an IPv4 and IPv6

address.

*4.5 Test-EPS-5: An ALTO client retrieves a Private Endpoint Property for an IPv4

address.

5. Endpoint Cost Service

5.1 Test-ECS-1: An ALTO client requests cost information between

individual endpoints.

5.2 Test-ECS-2: An ALTO client requests the ranking service for a

source host to a set of destination hosts.

5.3 Test-ECS-3: An ALTO client requests the cost service subject to

certain constraints.

6. Protocol Errors

*6.1 Test-ERR-1: An ALTO client sends a malformed JSON body in the

request --- a missing closing brace ('}'). (E_SYNTAX)

*6.2 Test-ERR-2: An ALTO client sends a malformed request --- the

"dsts" member for the endpoint cost service is missing. (E_MISSING_FIELD)

*6.3 Test-ERR-3: An ALTO client sends a request with an unexpected

type for a JSON value. (E_INVAILD_FIELD_TYPE)

*6.4 Test-ERR-4: An ALTO client sends a request with a wrong value for

a correct field. (E_INVAILD_FIELD_VALUE)

*6.5 Test-ERR-5: An ALTO client sends a request with multiple

errors.

> -----原始邮件-----

> 发件人: "Vijay K. Gurbani" <vkg@...>

> 发送时间: 2015-05-13 00:01:35 (星期三)

> 收件人: "郭华明" <guohuaming@...>

> 抄送: "Y. Richard Yang" <yry@...>, "IETF ALTO" <alto@...>

> 主题: Re: [alto] ALTO implementation interoperability

>

> On 05/11/2015 07:41 PM, 郭华明 wrote:

> > Dear Vijay, Richard,

> >

> > I am interested in this work. I will bring the test cases soon.

>

> Excellent. Please coordinate with the editors of the document with

> regard to bringing new test cases.

>

> Thanks for your time on this!

>

> Cheers,

>

> - vijay

> --

> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent

> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)

> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@...

> Web: https://urldefense.proofpoint.com/v2/url?u=http-3A__ect.bell-2Dlabs.com_who_vkg_&d=AwIGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=6h5yxyhxHTpCCwoZgmUqgGPoEl0VjBvG-QUM7wa8LTc&s=DkqHFvN8f463jbMtPlk51Ik2KCYpj3GA5ijiYZrxPXk&e= | Calendar: https://urldefense.proofpoint.com/v2/url?u=http-3A__goo.gl_x3Ogq&d=AwIGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=6h5yxyhxHTpCCwoZgmUqgGPoEl0VjBvG-QUM7wa8LTc&s=w302JfJ6Hg8_t-g1qcHO9XrAdCmuiD00QoI_kIn3M-M&e=

--

----------------

Best!

Huaming Guo

China Academy of Information and Communications Technology (CAICT)

No.36 A Nanlishi Road, Xicheng District, Beijing 100037, China

--
Richard