Hi Richard and all, Please see my comments inline.
Regards, Kai On 08/07/16 05:50, Y. Richard Yang wrote: > Dear all, > > We have made an initial design of the path vector design to support > the key application capacity region use case. > > Below is a list of key design reasoning: > - Current cost map and endpoint cost service is designed for the > setting of alternative flows, in that it asks for the cost of each > flow alone, but the capacity region is for concurrent flows. Hence, we > need a new request parameter to denote the new semantics---we could > use a new cost mode, but using a new design can be cleaner. > > - We want to support both endpoints and network maps (PIDs), when > querying capacity regions. Hence, the query, as an example > possibility, is: > > POST /capacityregion/lookup HTTP/1.1 > Host: alto.example.com <http://alto.example.com> > Content-Length: TBD > Content-Type: application/alto-flowparams+json > Accept: application/alto-costmap+json,application/alto-error+json > > { > "cost-type" : {"cost-mode": "path-vector", > "cost-metric": "bandwidth" > }, > "flows" : [ > {"src": "ipv4:192.0.2.2", "dst": "ipv4:192.0.2.89"}, > {"src": "ipv4:192.0.2.2", "dst": "ipv4:198.51.100.34"}, > {"src": "ipv4:192.0.2.2", "dst": "ipv4:203.0.113.45"}, > {"src": "ipv4:192.0.2.3", "dst": "ipv4:203.0.113.45"} > ] > } > > A possible encoding of response is: > > HTTP/1.1 200 OK > Content-Length: TBA > Content-Type: application/alto-costmap+json > > { > "dependent-vtags" : [ // defines the resource id providing nep > { "resource-id": "my-nep-map", > "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" > } > ], > > "meta" : { > "vtag" : { > "resource-id": "my-costmap", > "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d" > } > "cost-type" : {"cost-mode": "path-vector", > "cost-metric": "bandwidth" > }, > > "cost-map" : { > "ipv4:192.0.2.2": { > "ipv4:192.0.2.89": ["ne56"], > "ipv4:198.51.100.34": ["ne56", "ne57"], > "ipv4:203.0.113.45": ["ne57"] > }, > "ipv4:192.0.2.3": { > "ipv4:203.0.113.45": ["ne57"] > } > } > } > > The remaining issue is how to obtain the properties of the abstract > network elements. For this, we propose to use the unified properties > design: > https://tools.ietf.org/html/draft-roome-alto-unified-props-00 That doesn't seem like a good idea. First, the "network elements" are very likely to be request-specific, e.g., the element IDs are meaningful only for the given request while the unified property service is using a global namespace. Even if we can live with globally unique element IDs, ALTO clients may query the properties of network elements from different queries. That can be quite confusing so we'd probably have to make it clear that this must not be done. And the whole thing can lead to extra complexities to understand and implement the service. Second, using a second query may lead to inconsistency, even though the failure scenario may not be a big deal if the clients are not using incremental updates. However, it does require extra storage on the server to store the data when the clients are making one-shot queries. Of course, for the targeted scenario where flows have large volumes, one-shot queries are definitely not encouraged. One options, of course, is to encode the elements in the response. However, if UPS is desired, I suggest using a query-specific one instead of a global one, like the stream control URI used in the SSE draft. > Any comments? > > Cheers, > Richard > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
