Subject: Re: [alto] Work items for re-chartering

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 04 Feb 2014 12:27:27 -0600

On 01/31/2014 02:57 PM, Greg Bernstein wrote:
>> 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.

Greg: Good, what you write above appears to be a tractable and a
close-ended problem.

More inline.

>> 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).

Good, this seems to be heading in the right direction as well.

This has been an illuminating conversation, thanks for your time!

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-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 05 Feb 2014 08:06:08 -0800

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-masked]> 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].)
>>>
>>> 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.
>>> 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-masked]
>> https://www.ietf.org/mailman/listinfo/alto
>
>

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 5 Feb 2014 17:32:05 -0500

On Wed, Feb 5, 2014 at 11:06 AM, Greg Bernstein <[email-masked]
> wrote:

> 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

> >> (
> http://networkx.github.io/documentation/latest/overview.html#free-softwar
> >> e).

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================