Assuming we go forward with strict metrics, here is how we could do it
without breaking legacy clients.
There are two separate issues. One is letting clients know that a metric
obeys the requirements for a formal metric. That can be handled by
requiring anyone who registers a metric with the IANA to say whether or
not it is a formal metric.
The second issue is how to take advantage of the redundancy. If the server
just omitted the zero-diagonal and the lower half of the cost map for any
metric defined as strict, then a legacy client (or a smart client using a
legacy ALTO access library) will get an incomplete cost map. We can solve
that problem by defining a new cost mode, say "strict". This means that
for this cost-type, the server will omit the 0-diagonal and the lower half
of the cost map. The client is expected deduce those values.
Then if (say) the metric geo-distance obeys the formal metric rules, a
server can offer geo-distance in *both* the numerical & strict modes. The
strict-mode cost map omits the redundant cost points, while the
numerical-mode cost map includes them.
Thus a client which knows about the strict-mode extension will request
strict mode, and will supply the implicit costs. But a legacy client will
ignore the unknown mode, and will request the numerical mode instead. So
the legacy client still will get a valid geo-distance cost map, with all
the cost points. It just won't be as efficient.
Does that sound reasonable?
- Wendy
On 05/31/2015, 22:39, "Bertz, Lyle T [CTO]" <[email protected]>
wrote:
>Richard,
>
>You are not too far off at all. We need to think about this carefully.
>The team I work in is looking to set up topology information in such a
>way that NFV MANO and VIM decisions are simple while still providing some
>traditional transport optimization.
>
>I also think we may need theorems for aggregation of metrics. I'll have
>to dust off old work by various folks to see if it has not already been
>figured out.
>
>Since cost maps are directed there is no reason why we can't compute max
>and sum distance. This is practically an exercise left to the reader.
>The symmetric case would be new though.
>
>wrt the July question we may be able to do some work with the old code
>and there may be other code available as well but that will be quite new
>and full of bugs. I hope to confirm this before the end of June.
>
>Lyle
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
