Re: [alto] Design issue on path vector

[Jensen Zhang <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> on behalf of Chan Dawn
> <[e-mail]>
> Sent: Tuesday, March 21, 2017 13:02
> To: [e-mail]; [e-mail]
> 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