Hi Richard, Thanks for your feedback! See my comments inline:
Jensen On Thu, Mar 23, 2017 at 3:38 AM, Y. Richard Yang <[email protected]> wrote: > Dear Dawn, Jensen, > > Some comments. Please see below inline. > > On Tue, Mar 21, 2017 at 1:02 PM, Chan Dawn <[email protected]> wrote: >> >> 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"] >> } > > I assume that the same IRD will also have an entry for "default-nep-map" and > there is also a definition for "pv". You omitted them in this example, > correct? Yes, they are also in the same IRD. >> 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. >> > A resource ID is a name to be used in the IRD to provide the needed query > information (e.g., uri) to obtain related information. If the pv resource > returns an property name (dynamic), and the property resource has an accept > of the dynamic property name, can this solve your problem? > Let me understand your proposal. Is it like the following? ECS response meta: "meta": { "dependent-vtags": [ { "resource-id": "default-nep-map":, "tag": "<sha256>" } ], "cost-type": { "cost-mode": "path-vector", "cost-metric": "ane" }, "query-id": "<A Query Specific ID>" } And nep-map request: "query-id": "<The Same Query as the One in the Response>", "entities": ... "properties": ... So every nep-map should be identified by <resource-id, tag, query-id> rather than only <resource-id, tag>? It seems to be a solution. Let me think about it. >> 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. > > One possibility is that a pv resource also indicates the metrics that it can > provide, i.e., > > “pv-endpoint-cost-map”: { > “uri”: “http://alto.example.com/lookup/endpointcost”, > “media-type”: “application/alto-endpointcostmap+json”, > “capabilities” : { > “cost-type-names”: [“pv"] > // define metrics here?? > }, > “uses”: [“default-nep-map"] > } > Yes, it is a solution. And we tried to propose the same solution. But it will introduce an extra capability. And only when the cost-mode is "path-vector", this capability can be enabled. So it is too specific. How do you think? >> 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. >> > This is a good point. We need to think a bit hard on incremental updates. A > reply will come shortly. > Looking forward. >> 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 >> } >> }, >> > This "immediate-use" design reminds me of nameless inner class/object. Does > this require that the resource in the "immediate-use" to use the same uri as > the "parent" uri? > What's the meaning of "parent" uri? A prefix of the uri? If so, I think it is a good proposal. >> 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? >> > > It is a quite interesting design. If we can modify the incremental updates > to include not only resource id but also some additional info, can the > problem be solved? > Although we can extend incremental updates to include additional info, I think the resource id is still a required attribute. Because we need a unique id to identify the resource. A potential way is to use "uri" instead of "resource-id"? But for incremental update service, resource "uri“ cannot be used to index the resource attributes such as "media-type" and "capabilities". > Richard > >> >> Thanks a lot! >> >> Dawn Thanks a lot! _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
