[alto] Discussion on how to encode element values of a cost map

["Y. Richard Yang" <[e-mail]>]

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/