Hi Richard, 2. For the property graph foundation, I think separating PIDs from network nodes is a cleaner design for the following reasons: (1) The alto topology service will be able to hide unnecessary information from clients who don't need it. e.g. if an alto client don't need topology at all and simply requested the network map, the server would not need to send all the network nodes as PIDs in the network map. (2) One argument of unifying network nodes with PIDs is the homogeneity when processing the topology map. However, the server or the client would still need to distinguish whether a node is a PID or a network node because PIDs don't relay. (3) PID property service would indeed make encoding network node properties convenient. In a property graph, one can use the node properties to encode properties for network nodes, which is not too bad either.
3. by "subgraph selection API," I assume that you meant the transformation and operations in Appendix A of the document? There could be two options for the user input, depending on where the majority of the computational burden falls (client side vs. server side.): (1) if the client sends a set of (src, dst) PID pairs to the server, indicating that those are the interested routes, the client will need to provide a cost-metric calculation function (e.g. hopcount, avail-bandwidth, etc), which might be hard to encode in the HTTP request/hard to define. (2) The alternative is for the server to send a default high level topology upon request, then the client further request on details that it's interested in (i.e. zooming in). The computational burden falls on the client side in this case. Remaining questions are how does the client know where to "zoom in," perhaps on common vertices/edges between its interested paths? My two cents, Xiao On Fri, Nov 7, 2014 at 3:28 PM, Y. Richard Yang <[email protected]> wrote: > Dear all, > > As we are preparing for the slides on a potential ALTO topology extension > (node-link graph), we have a few design choices that can benefit from some > discussions in the WG list. > > 1. path vector vs flow > > Starting from -03, the document introduced the concept of a path vector > mode as a generic mechanism to provide topology/routing information. Upon > writing the slides, however, we found that to handle multi-path routing > (e.g., ECMP), we will need a simple flow routing concept, where path vector > is a special case. Any comments on extending to this direction will be > appreciated. > > 2. property graph as a node-graph foundation > > Another design choice, when introducing node-link graph, is > (1) adding network nodes in the network map, and hence we have a single > place for all network nodes, and PID properties can provide properties for > all such nodes; or > (2) separate PIDs (endpoint user groups) from network nodes. This may be > conceptually cleaner. Then it implies two types of links, which will be > captured by property graphs. > > If you have any comments on this aspect, please share your opinions. > > 3. Subgraph selection API > > How to provide a generic mechanism to allow an ALTO client to select a > subgraph is still not clear--it will depend on the use cases. So far, the > first selection service is the expander of a given set of src/dst PIDs: the > expander is the union of path vectors (or flows, if we consider > multi-path). If you have any opinions on this aspect, please let us know. > > Cheers, > > Richard > > ---------- Forwarded message ---------- > From: <[email protected]> > Date: Mon, Oct 27, 2014 at 7:41 PM > Subject: New Version Notification for draft-yang-alto-topology-05.txt > To: Greg Bernstein <[email protected]>, Michael Scharf < > [email protected]>, Wendy Roome < > [email protected]>, Young Lee <[email protected]>, "Y. Richard > Yang" <[email protected]> > > > > A new version of I-D, draft-yang-alto-topology-05.txt > has been successfully submitted by Y. Richard Yang and posted to the > IETF repository. > > Name: draft-yang-alto-topology > Revision: 05 > Title: ALTO Topology Extensions > Document date: 2014-10-27 > Group: Individual Submission > Pages: 18 > URL: > http://www.ietf.org/internet-drafts/draft-yang-alto-topology-05.txt > Status: https://datatracker.ietf.org/doc/draft-yang-alto-topology/ > Htmlized: http://tools.ietf.org/html/draft-yang-alto-topology-05 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-yang-alto-topology-05 > > Abstract: > The Application-Layer Traffic Optimization (ALTO) Service has defined > network and cost maps to provide basic network information. In this > document, we discuss designs to provide abstracted graph > representations of network topology. We start with a basic > application use case of multi-flow scheduling using ALTO. We show > that ALTO cost maps alone cannot provide sufficient information. We > then define one key, generic component to address the issues: > introducing path vectors in cost maps. We specify two approaches to > complement path vectors and achieve a complete design: an approach > using opaque network elements and another using a graph (node-link) > representation. > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
