Richard Alimi a écrit :
I don't have any objections with leaving this as an extension.
Sabine - are you still intending to fill out the details in
draft-randriamasy-alto-multi-cost? Perhaps that could be the first
ALTO protocol extension :)
Hi
Yes, I am working on it. The trade-off between options 1 and 2, depends
on the service.
- For the EP Cost Service, (POST method), option 2 providing a vector
or array of multiple EP Costs or Properties seems to be the simplest way.
- For the Filtered Cost Map service (POST method), option 2 also looks
easily feasible if the filtered volume of information is moderate
(assuming we know what moderate means).
The 2 above services use an order for the components of the
cost/properties vector that is specifed in the IRD of the ALTO Server.
Which means that the multi-Cost/Property Service would be implicitely
declared in the IRD.
- For the Cost Map Service (Get method), we may bump into scalability
issues id the map is "too big". In that case option 1 looks preferable,
with possibly a limitation on the number of Cost maps per ALTO
transactions specified in the IRD.
Sabine
I could imagine a couple of ways the extension could go:
(1) Design a new service such as the multicost map service. This is
easy within the current protocol (adding new services to the IRD is
easy without breaking existing clients).
(2) Treat queries for multiple cost types the same as a query for a
cost type that is vector (I think this was basically the way we were
heading in the design discussion previously on the list). I think
this requires a bit of a change to the base protocol, but one that we
proposed a while back (in particular, opaque cost types). I'll ping
that thread to see if there are any objections to adding that in this
revision and we can discuss on that thread if there are.
Thanks
Rich
On Sat, Aug 27, 2011 at 12:29 PM, Reinaldo Penno <[email protected]> wrote:
I prefer 1.
On 8/26/11 11:01 PM, "Enrico Marocco" <[email protected]>
wrote:
The current specification allows cost maps to convey only one type of
cost information at a time. It has been pointed out that, in some cases,
applications may benefit from the presence of multiple cost-type values
in a single cost map (see draft-randriamasy-alto-multi-cost for a
detailed description of such use cases) and an extension for allowing
that has been proposed.
Possible options (please express and possibly motivate your preference):
1. allow only one type per cost map in the core protocol
specification and define the syntax and usage of multi-cost maps
as an extension;
2. extend the core protocol specification to allow multi-cost
information to be queried and provided in base responses;
3. other.
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
--
---------------------------------------------------------
Sabine RANDRIAMASY
Alcatel-Lucent Bell Labs France
Centre de Villarceau
Route de Villejust - 91620 NOZAY - FRANCE
E-MAIL : [email protected]
TEL: +33 (0)1 30 77 27 45
(On Net) 2 103 27 45
---------------------------------------------------------
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
