Personally speaking, I think there are two issues about cost-type
definition:
1) How to make the compound type compatible with RFC7285;
2) How to extend single cost-type easily. (Maybe we want to support generic
types)
A simple design I think is to introduce a special cost-mode called
"compound". When cost-mode value is "compound", "multi-cost-types" field
will be required. If the cost-mode value is not equal to "compound", we
need to suppose the cost-type is always a single type.
I don't think about the benefit from supporting generic types very clearly.
We can introduce another some basic cost-mode like identity, vector and map.
The recommended usage can look like:
if meta.cost-type.cost-mode == "compound"
ElemType is array && "multi-cost-types" field is required
else if meta.cost-type.cost-mode == "numerical"
ElemType is number
else if meta.cost-type.mode == "ordinal"
ElemType is non-negative int
else if meta.cost-type.mode == "identity"
ElemType is string
else if meta.cost-type.mode == "vector"
ElemType is array
else if meta.cost-type.mode == "map"
ElemType is object
I think it is general enough to express arbitrary JSONValue. But I am not
sure making the cost-mode cover generic types is helpful. Actually,
"vector" and "map" are not single types. They are compound types indeed. If
we want to express the cost-type accurately, one solution I think is to
introduce a new field called "cost-schema" in cost-type:
object {
CostMetric cost-metric;
CostMode cost-mode;
[CostSchema cost-schema;]
[JSONString description;]
} CostType;
The cost-schema field for cost-type is just like DTD for xml. And we can
design complex compound types by using cost-schema.
But I don't plan to deprecate "multi-cost-types" field. Because I think
multi-cost is not a compound type but a class of compound types. For
example, cost-maps with multi-cost [bw, hopcount] and with [hopcount,
delay] can have the same capability [bw, hopcount, delay].
The above is my current thought.
Best,
Jensen
On Mon, Jul 18, 2016 at 8:11 AM, Y. Richard Yang <[email protected]> wrote:
> Hi all,
>
> Several of us are reviewing the documents in the WG. Here is one common
> issue: We see that quite a few documents depend on encoding the types of
> the elements in a cost map. This is a complexity that the based protocol
> RFC7285 identifies and hence decided to make the type the generic type
> JSONValue. But in the spirit of being strong typed, a specific cost map
> needs an indication of the type. For those who need some review, please see:
>
> - Cost Map response: https://tools.ietf.org/html/rfc7285#section-11.2.3.6
> Requirements:
>
> media-type: application/alto-costmap+json
>
> meta: MUST include cost-type and dependent-tag of the network map
>
> data: "An implementation of the protocol in this document
> SHOULD assume that the cost is a JSONNumber and fail to parse if it
> is not, unless the implementation is using an extension to this
> document that indicates when and how costs of other data types are
> signaled."
>
> - Filtered Cost Map response:
> https://tools.ietf.org/html/rfc7285#section-11.3.2
>
> Defined as the same as Cost Map.
>
> - Endpoint Cost Service:
> https://tools.ietf.org/html/rfc7285#section-11.5.1
>
> media-type: application/alto-endpointcost+json
> meta: "The "meta" field of an endpoint cost response MUST include the
> "cost-
> type" field, to indicate the cost type used."
>
> The current definition of cost-type has two components: cost-mode and
> cost-metric,
> and cost-mode has two values defined: numerical and ordinal, both indicate
> a single
> number. At the same time, multiple active drafts (
> https://datatracker.ietf.org/wg/alto/documents/)
> need compound types for the elements of a cost map:
>
> - [multi-cost]
> This draft is probably the one which we need to resolve the issue the most
> urgent. Assume that
> it uses the current alto-costmap+json media type, then it cannot satisfy
> the requirement of "meta"
> including cost-type.
>
> - [cost-calendar]
> Cost calendar requires a compound data type as well.
>
> - [fcs]
> fcs depends on multi-cost and hence can have an issue as well.
>
> - [path-vector]
> The current definition of path-vector needs a vector of network elements.
>
> - [te-metrics]
> It appears that this document is fine, but may need to watch on related
> consistency issues.
>
> The preceding is not a minor syntax/encoding issue. How to handle types is
> a basic problem.
> Conceptually, a cost map, as in the base protocol is param'ed type:
> Map< String, Map< String, ElemType > >
>
> (Note: Some may argue that String above should be typed identifier.)
>
> So far, we have defined ElemType to be JSONValue, and used the cost-type
> to indicate more specifics:
> if meta.cost-type.cost-mode == "numerical"
> ElemType is float
> else if meta.cost-type.mode == "ordinal"
> ElemType is non-negative int
>
> My personal feeling is that we may need to start to introduce new
> cost-mode values to allow generic types. For those who are PL experts, it
> is a good chance to chime in. It is an important issue that the WG may want
> to work together to achieve a consistent, extensible design.
>
> Cheers,
> Richard
>
> References:
> - [multi-cost]
> https://datatracker.ietf.org/doc/draft-ietf-alto-multi-cost/
> - [cost-calendar]
> https://datatracker.ietf.org/doc/draft-randriamasy-alto-cost-calendar/
> - [fcs] https://datatracker.ietf.org/doc/draft-gao-alto-fcs/
> - [path-vector]
> https://datatracker.ietf.org/doc/draft-yang-alto-path-vector/
> - [te-metrics] https://datatracker.ietf.org/doc/draft-wu-alto-te-metrics/
>
> _______________________________________________
> alto mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/alto
>
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
