Re: [alto] Design issue on path vector

[Dawn Chan <[e-mail]>]

Hi Richard, Jensen

Thanks for your new ideas, please see my comments inline.

On Mar 24, 2017, at 8:35 AM, Y. Richard Yang <[e-mail]<mailto:[e-mail]>> wrote:

Jensen, Dawn,

Please see below.


>> 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 a 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.

Yep. Essentially, since we have the freedom to design property map---it is great that we are designing PV before the property, we can add needed info.


I think this design idea is quite similar to what Jensen posted previously. That is, the “resource-id” of a nep-map is fixed but the nep-map itself is dynamic. To distinguish the network elements names between different queries, the names in the nep-map uses different prefixes
of ane names to ensure there is no same ane name in different responses, but this design idea doesn’t require new field name.

Also, since the nep-map will be enriched when new queries appear, the “tag” field in “dependent-vtags” is useless to reference the nep-map, right?

>> 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?

Agree with your thinking. The downside is that the domain of capabilities will depend on the content, and hence static typing will not work. But I feel that this is a small price.

I think no more capabilities are needed here. From the “uses” field, the client can get the information about what property types the nep-map resource support, so we don’t need to list the property types in the ECS’s capabilities, right?

>> 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.


Yep.

>> 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".

Good point.

Richard