Thanks for the detailed references Jan. I've looked at the Yang network topo draft and the OpenDaylight JSON format. This is very similar to what we'd want. Though there are some more items that we'd like included. If there is sufficient interest we can put an extended comparison of models and JSON formats into a draft.
Cheers Greg On 1/31/2014 2:48 PM, Jan Medved (jmedved) wrote: > 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 > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
