Hi Vijay, see comments below. Cheers Greg On 1/29/2014 3:04 PM, Vijay K. Gurbani wrote: > 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? --> NetworkX originated with a government research project is is open sourced under BSD (http://networkx.github.io/documentation/latest/overview.html#free-software). Hard to exactly say what the Tinkerpop open source license is (https://github.com/tinkerpop/blueprints). However, neither of these is formally defined at a sufficient level for standardization purposes, i.e., not even close to the JSON standardized in the current ALTO spec. As Michael pointed out the structure of a graph in JSON via node lists and link lists with properties is a fairly generic notion. We'd need to formalize it for interoperability sake. Note also that representing paths as a list of links (link-path representation) is also fairly generic. > > 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. --> Not sure if this is possible. Was having related discussions with Wendy and Richard, they may have more ideas on this. > > 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. --> Either the client or the server but not part of the standard. How a network provider wants to represent their network to a client is their business. In the case of controlled environments (VPN) the provider may customize what they show to a particular client (based on pre-arranged information that is out of our scope). > > 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
-- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
