Network topology as a list of nodes and links is defined in http://datatracker.ietf.org/doc/draft-clemm-netmod-yang-network-topo/. This draft is implemented in the OpenDaylight controller as a part of the Hydrogen Service Provider edition. OpenDaylight supports RESTconf v02 (http://datatracker.ietf.org/doc/draft-bierman-netconf-restconf) on its NB interface and can provide data (including topology graphs) to clients in both XML and JSON formats. OpenDaylight is open sourced under EPL.
Thanks, /Jan On 1/31/14, 12:57 PM, "Greg Bernstein" <[email protected]> wrote: >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-softwar >e). >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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
