Hi Dawn, Thanks for starting this discussion.
Hi Xin, Thanks for your comments. See inline. Jensen On Wed, Mar 22, 2017 at 12:32 PM, xin wang <[email protected]> wrote: > Hi Dawn, > > > If I am wrong please correct me. For the second issue, the resource id could > be reflected in the hash code of the uri field. I think you are missing that > in your ECS example. I think "uri" and "resource-id" are very different. How can we reflect the "resource-id" in the "uri"? Do you want to introduce the extra semantics into the "uri"? > For the first issue, in my understanding, since network > elements are dynamically generated after the computation of path-vector, I > think it is hard to determine element property types before the computation. > This may depend on whether we support "unknown" in the response of network > element property map, i.e., > > "property-map": { > "ne:ne12": { "availbw": "90", "delay": "unknown" }, > "ne:ne23": { "availbw": "80", "delay": "15" }, > "ne:ne34": { "availbw": "70", "delay": "25" } > } Please notice that "prop-types" is a capability of "prop-map". If this "prop-map" does not support "delay", it will be determined before you send any query. And you even cannot query "delay" to this "prop-map". "unknown" does not solve this issue. I think what we are discussing is that if the ALTO server provides a "path-vector" FCM resource, it should inform the client which "prop-types" will be supported by the generated "prop-map" at an earlier stage. If you provide this information in the response of FCM rather than the IRD entry of it, the client may have to send a useless FCM query before it gets this information. > > > Best, > Xin > > ________________________________ > From: alto <[email protected]> on behalf of Chan Dawn > <[email protected]> > Sent: Tuesday, March 21, 2017 13:02 > To: [email protected]; [email protected] > Subject: [alto] Design issue on path vector > > > Hi all, > > > I'd like to start a discussion for path-vector design and push it as an > acceptable specification. Following is my thought: > > > We have agreed on delivering path-vector + abstract network elements design > for net graph representation since IETF 96. This design specifies the cost > value as a path vector which is a JSONArray of network elements and puts the > network element properties into a nep-map. Considering to reference the > nep-map from another resource (we propose to use unified-prop-map), below is > a naive design: > > > > An example of IRD: > > > “pv-endpoint-cost-map”: { > > “uri”: “http://alto.example.com/lookup/endpointcost”, > > “media-type”: “application/alto-endpointcostmap+json”, > > “capabilities” : { > > “cost-type-names”: [“pv"] > > }, > > “uses”: [“default-nep-map"] > > } > > > An example of ECS response: > > > “meta”: { > > “dependent-vtags”: [ > > { “resource-id”: “default-nep-map”, “tag”: “<sha256>” } > > ], > > “cost-type”: {“cost-mode”: “path-vector”, “cost-metric”: “ane”} > > }, > > “endpoint-cost-map”: ... > > > However, the problem is how to reference the filtered property map that we > use for clients to retrieve the properties of the corresponding network > elements. In the above example, the referenced network element property map > is added in the “uses” field. However, here is the trouble: > > > Since the network elements are abstract, the network element property map is > dynamically generated when the client sends a path-vector query. So, to add > the refrenced network element property map in the “uses” field of a resource > is not possible because the resource id in the “uses” field is somehow > static, it already exists before queried. > > > To solve this problem, we proposed the following design in > draft-yang-alto-path-vector-04: > > > An example of ECS response: > > > “meta”: { > > … > > "nep-map": { > > "uri": "http://alto.example.com/propmap/lookup/nep-map";, > > "media-type": "application/alto-prompmap+json", > > "accepts": "application/alto-propmapparams+json", > > "capabilities": { > > "domain-types": [“ane"], > > "prop-types": ["availbw"] > > } > > } > > }, > > “endpoint-cost-map”: ... > > > But we found two issues in this design: > > > 1. How to present the supported properties of the network elements in the > IRDResourceEntry of a resource? In this example, the nep-map can only > provide the “availbw” property. If the client needs the “delay” property of > the returned network elements, it cannot get this knowledge that the > dependent nep-map of this ECS resource does not provide this property before > it sends the query. So the client will send a useless query. > > 2. This design does not provide a resource-id for the nep-map, so the server > cannot provide an incremental update service for the nep-map. > > > We found the fundamental problem is caused by the dynamic resource. In the > previous ALTO extensions, all the resources can be defined by the static IRD > Resource Entries. But in this case, we have to handle the dependency > relationship between FCM/ECS and a dynamic property map resource. So we > propose the following design to solve this problem: > > > 1. Add a new attribute in the IRDResrouceEntry: > > > object { > > JSONString uri; > > JSONString media-type; > > [JSONString accepts;] > > [Capabilities capabilities;] > > [ResourceID uses<0..*>;] > > [ImmediateResourceEntry immediate-uses<0..*>;] > > } IRDResourceEntry; > > > object { > > JSONString media-type; > > [JSONString accepts;] > > [Capabilities capabilities;] > > [ResourceID uses<0..*>;] > > } ImmediateResourceEntry; > > > 2. Add a new attribute in the meta of FCM/ECS response: > > > object { > > [JSONString vtag;] > > [VersionTag dependent-vtags<1..*>;] > > [ImmediateVersionTag immediate-dependent-vtags<1..*>;] > > } ResponseMeta; > > > object { > > ResourceID resource-id; > > JSONString vtag; > > [JSONNumber time-out;] > > } ImmediateVersionTag; > > > Here is an example: > > > IRD: > > > "pv-endpoint-cost-map": { > > "uri": "http://alto.example.com/lookup/endpointcost";, > > "media-type": "application/alto-endpointcost+json", > > "accepts": "application/alto-endpointcostparams+json", > > "immediate-uses": [ > > { > > "media-type": "application/alto-propmap+json", > > "accepts": "application/alto-propmapparams+json", > > "capabilities": { "domain-types": ["ane"], > > "prop-types": ["availbw", "delay"] } > > ], > > "capabilities": { > > "cost-type-names": ["pv-ane", "num-routingcost", "num-hopcount"], > > "cost-constraints": true > > } > > }, > > > Response: > > > { > > "meta": { > > "cost-type": { > > "cost-mode": "path-vector", > > "cost-metric": "ane", > > }, > > "immediate-dependent-vtags": [ > > {"resource-id": "nep-map-<sha256>", > > "vtag": "<sha256>", > > "time-out": 180} > > ] > > }, > > "endpoint-cost-map": { > > ... > > } > > } > > > Shall we push this design into the pv draft? Any feedback from others? > > > Thanks a lot! > > Dawn _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
