Hi Dawn, Thanks for your reply. Comment inline.
Thanks, Jensen On Mon, Jun 26, 2017 at 5:08 PM Dawn Chan <[email protected]> wrote: > Hi Jensen and all, > Sorry for the late reply. Please see my comments inline. > > On 7 Jun 2017, at 4:52 PM, Jensen Zhang <[email protected]> > wrote: > > Hi all, > > I am going to resume the discussion about graph representation and path > vector. After some attempts to adopt the path-vector extension, I have the > following considerations: > > 1. The current design is inefficient. Since IETF 98, we have agreed on the > design of a two-stage protocol extension (path-vector cost map + unified > property map) for graph representation. It is extensible enough because we > can customize the element (ane) properties. But the two-stage protocol will > conduct the long delay and increase the complexity of state maintenance. > > 2. The resource dependencies are not clear. The "Dependent Resources" > attribute in ALTO protocol is defined to claim the one-way resource > dependencies. But many resource dependencies should be bidirectional. e.g. > In path vector design, the cost map and the corresponding property map are > bound to the same query. > > For 1, my personal idea is to deliver a service to accept a sequence of > queries. In this way, the client can query both cost map and property map > in a single request. And the server will handle the two-stage protocol > efficiently. > > Here is a rough example: > > request: > - resource: /alto/pv-costmap > pids: > - srcs: [xxx] > - dsts: [yyy] > - resource: /alto/ane-prop-map > query-id: $resource[0].$response.meta.queryId > entities: $resource[0].$response.costmap.values.reduce( > (x,y) => x.values.concat(y.values)) > > This design idea is a one-step service to get the cost map response and > the property map response together in one request, which means it will > return all the abstract network elements generated by one query. The effect > of this design is probably same as the inline-mode that will directly > return the properties of anes in the cost map, right? > > Not exact. The inline-mode pv design just provides one resource. This idea proposes a complete grammar of a query language. The response contains multiple resources. The PV query is just a special example. The design can also be used in other query combinition, e.g. Network Map + Cost Map. And the client can offload some computation on the server part. > > For 2, I have not found a good solution to handle the generic case. > > Looking forward to any feedback. > > Best regards, > Jensen > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
