I just realized that the example I took to explain how to query pv-cost-map + ane-prop-map may make people confused.
Ideally, I hope to provide a general query service to handle some batch query or some resource combination query. I want to know how many people are interested in this idea or think it is useful. To make the discussion more efficiently, I will post an initial draft to define the formal grammar asap. Best, Jensen On Mon, Jun 26, 2017 at 10:04 PM Jensen Zhang <[email protected]> wrote: > 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
