Subject: Re: [alto] Unifying cost-mode and cost-type

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 05 Feb 2013 14:42:47 +0000

Hi,

I think your proposal on adding this metadata on what an ALTO server provides makes a lot of sense, especially if we think about the additional usages of ALTO that were originally discussed in the i2rs BoF in Paris, and that I'd say have raised so much expectation among the SDN community, among others.

Therefore, I'd like very much to see this discussion happening within the ALTO group, mostly once we have been able to complete the current set of documents and we are in the position of re-chartering the group along the lines discussed in the Paris BoF.

Be goode,

On 30 Jan 2013, at 20:12 , Wendy Roome wrote:

> I realize it's late to make changes, but I really think unifying type &
> mode makes a lot of sense.  Here's my suggestion: extend the "resource
> directory" to include a generalized description of the cost-types that the
> server provides.  I won't suggest a syntax -- too early for that!! -- but
> here's what the description should provide for each distinct type:
>
> * The type name.  This is what clients give in the cost-type parameter.
>
> * The value type.  "numerical" & "string" are obvious possibilities.
>
> * Linear: a boolean flag. True means this numeric value is linear.
>  False means values are not linear. This takes the place of
>  the ordinal/numerical mode.
>
> * Category: What this cost measures: "delay", "hops", "cost", "other".
>  Here "cost" means money.
>
> * Description: An optional free-form description of this cost type.
>  For human consumption, to be used when investigating a new ALTO server.
>
> * URL: An optional url with a detailed description of this cost type.
>  For more involved "Descriptions", of course. This can be in
>  multiple languages, of course.
>
> Yes, the change would be painful, but I think it will simplify the
> protocol, servers and clients -- AND it will make it easier for servers to
> add new cost types.
>
> To simplify clients, we might reserve a few type names, such as
>   routingcost-numerical
>   routingcost-ordinal
>   hopcount-numerical
>   hopcount-ordinal
> and require them to have the obvious descriptions.
>
>       - Wendy Roome
>
>
>
>
> On 01/29/2013 15:00, "[email-masked]" <[email-masked]> wrote:
>
>> Date: Mon, 28 Jan 2013 23:08:23 +0000
>> From: "Reinaldo Penno (repenno)" <[email-masked]>
>> To: "[email-masked]" <[email-masked]>
>> Subject: [alto] ALTO Protocol Outstanding Issue II: Unifying cost-mode
>>      and cost-type to a single type
>> Message-ID:
>>      <[email-masked]>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Hello,
>>
>> Please send your comments to the list in the next 2 weeks. Silence means
>> we will go with the proposal.
>>
>> Discussion II: Unifying cost-mode and cost-type to a single type
>>
>> e.g., routingcost-num and routingcost-ord
>>
>> Having a single type simples the protocol since there is just one
>> parameter when indicating cost. But it will impact current
>> implementations and might loose flexibility.
>>
>> Proposal: Leave it as is.
>>
>> Thanks,
>>
>> Reinaldo
>>
>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Sabine Randriamasy <[email-masked]>
Date: Thu, 7 Feb 2013 18:32:13 +0100

Hello,

I'd also go for unifying cost-type and cost-mode in one type name. One 
of the reasons is that it would spare the time of parsing ALTO requests 
and responses to detect incompatible cost types and modes or mismatched 
cost types and cost mode lists.
We need these explicit description attributes indicating how to use the 
values and value types covering all the JSON types.
The important thing is to keep the possiblity to extend the cost types 
and cost modes.

Cheers
Sabine