Michael, Greg: Great dialogue. I think as a general deliverable for "An ALTO format for encoding graphs", this dialogue has shed some clarity on what could be the outcome of such a deliverable. The scope of what goes into encoding the graph would be something that we should discuss as well.
It appears that normal attributes associated with graph representation are in scope, and these include labels for vertices and edges, in-degree and out-degree for vertices, the pair of vertices an edge connects, and a set of properties associated with edges and vertices. (This is essentially the "property graph" model you outline in [1].) I'd like to see what the thoughts are of you (and the working group) on whether we end up using an existing format (and how that will actually work with respect to the copyright holders, if any, of the existing format) or do we come up with a new one? Another question to consider is whether this new format will subsume the existing topology map and cost map as well? Or does this new format only model individual hosts and the links connecting them and stays away from representing the hosts in the aggregate (the PID concept)? Usages of ALTO that will benefit from existing concepts (PIDs, pairwise costs) can continue to use the existing topologies and cost maps. Usages of ALTO that need more detailed knowledge of individual hosts and link can use the new extension format for encoding graphs. Regarding the second sub-issue on the need for reductionist algebra for graph transformations, I agree with you [1] that we leave that up to the ALTO client. I believe that such a strategy will allow Greg to derive "service-specific" graphs that are transformed from an original graph. Since the specific need for such "service-specific" graphs will be a function of what the ALTO client wants, it seems reasonable to provide building blocks in the form of an extension for encoding graphs that can be coupled with the extensions for TE metrics (draft-wu-alto-te-metrics). It is up to the ALTO client to put these together in some fashion that satisfies its constraints. This will leave us with a reasonable and tractable problem to come up with an extension to encode graphs, hopefully in a short time frame. [1] http://www.ietf.org/mail-archive/web/alto/current/msg02365.html Looking forward to your responses and insights. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / [email protected] Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
