Re: [alto] Design issue on path vector

["Y. Richard Yang" <[e-mail]>]

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.


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


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