Re: [alto] Design issue on path vector

[Jensen Zhang <[e-mail]>]

Hi Richard,

Thanks for your feedback! See my comments inline:

Jensen

On Thu, Mar 23, 2017 at 3:38 AM, Y. Richard Yang <[e-mail]> wrote:
> Dear Dawn, Jensen,
>
> Some comments. Please see below inline.
>
> On Tue, Mar 21, 2017 at 1:02 PM, Chan Dawn <[e-mail]> 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!