On Wed, Feb 5, 2014 at 11:06 AM, Greg Bernstein <[email protected] > wrote:
> 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. > A comparison of models and JSON formats can be a great starting point. It will inform the WG what has already been done, and at the same time shows that there is a base. Richard > > 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 > -- -- ===================================== | Y. Richard Yang <[email protected]> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
