Hi Kai, On Thu, Jul 7, 2016 at 10:35 PM, Gao Kai <[email protected]> wrote:
> 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 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__alto.example.com&d=CwMD-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=c7YHdBafx9Hhdqqb8Cn47RLAJcr6jjZs_orqdAOojPw&s=kmAR7JkZey89dhUxg429u46yO5rn0DYUb1Q-XKIm924&e=> > 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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Droome-2Dalto-2Dunified-2Dprops-2D00&d=CwMD-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=c7YHdBafx9Hhdqqb8Cn47RLAJcr6jjZs_orqdAOojPw&s=kpwxnZwaBbAmP5fl-gMCGJjKZzWkK4GalhqS9Mm1vw0&e=> > > 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. > Excellent comments! My original intention was to separate the path vectors from the vector-element properties so that the property updates can be through a different channel. You made an excellent point and I agree that encoding in the same makes more sense. Richard > 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 [email protected]https://www.ietf.org/mailman/listinfo/alto > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=CwMD-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=c7YHdBafx9Hhdqqb8Cn47RLAJcr6jjZs_orqdAOojPw&s=KAyMDy4aMsmOVHWJCPmyzWU9GnX9L-dWUW3Rnxv2Lig&e=> > > > -- -- ===================================== | Y. Richard Yang <[email protected]> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
