Dear Dawn, Jensen, Some comments. Please see below inline.
On Tue, Mar 21, 2017 at 1:02 PM, Chan Dawn <[email protected]> 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? > 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? > 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"] } 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. > 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? > 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? Richard > Thanks a lot! > > Dawn >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
