My comments on draft-kiesel-alto-xdom-disc-02:
Section 1:
You might mention that yet another problem with the 1.? solutions is that
the values of ALTO cost metrics are not standardized. For example, there
is no standard definition of what "routingcost 10" means. Hence cost
metric values are not comparable between ALTO servers.
This is also a problem for 2.1, because the client cannot tell if the
returned costs are from the server it contacted directly, or from some
other server.
Section 3.2:
If a client wants the cost from X => Y, why just do cross-domain discovery
on address X? Why not do it for Y instead? Or do it for both X & Y?
Section 3.3:
This also has the problem that cost metric values are not standardized,
which will make it very difficult to merge costs from multiple ALTO
servers into a single cost map.
Also, I think you mean "NxN cost map" rather than "NxN network map".
Section 4.2.1:
"or redirect the client to another ALTO server using mechanisms of the
ALTO protocol (see Sect. 9 of [RFC7285])."
Does that refer to a root IRD referencing a secondary IRD, as described in
Section 9.2.4? If so, I don't think of a secondary IRD as representing a
different ALTO server. Rather, I regard secondary IRDs as distributing the
resources of one ALTO server over several physical processors. I assumed
that the set of resources from the root IRD and secondary IRDs were
managed by the same entity, and used the same cost metric definitions, so
that cost metric values obtained from any of those resources could be
safely compared with each other.
- Wendy Roome
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
