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
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
