Re: [alto] 答复: Design issue on path vector

[Jensen Zhang <[e-mail]>]

I'm thinking about whether the design can be simpler. Here is another
design to solve the dynamic nep-map issue:

We do not extend any scheme but make every path-vector queries share
the same nep-map resource.

Here is an example nep-map resource in the IRD. It is a filtered
property map as the same define in [0].

This resource supports the "availbw" and "delay" property types.
Initially, this resource may be empty with no abstract network
elements.

  "default-nep-map": {
     "uri": "http://alto.example.com/propmap/nepmap/default",
     "media-type": "application/alto-propmap+json",
     "accepts": "application/alto-propmapfilter+json",
     "capabilities": {
       "domain-types": ["ane"],
       "prop-types": ["availbw", "delay"]
   }

The ECS resource uses "default-nep-map" as the dependent resource.
(Just like the naive design.)

  “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"]
  }

Each query will share the same dependent resource. But the ane names
in different responses MUST be different. There are two different
queries for the same ECS resource.

ECS Response of Query1:

  {
    "meta": {
      "cost-type": {
        "cost-mode": "path-vector",
        "cost-metric": "ane",
      },
      "dependent-vtags": [
        {"resource-id": "default-nep-map",
         "vtag": "[TBD]",}
      ]
    },
    "endpoint-cost-map": {
      "ipv4:192.168.1.101": { "ipv4:192.168.1.201": ["ane:QabcdL0001",
"ane:QabcdL0002"] },
      ...
    }
  }

After the above query, "ane:QabcdL0001" and "ane:QabcdL0002" will be
added into the "default-nep-map".

ECS Response of Query2:

{
  "meta": //The same meta
  "endpoint-cost-map": {
    "ipv4:192.168.1.102": { "ipv4:192.168.1.202": ["ane:QabdeL0001",
"ane:QabdeL0002"] },
    ...
  }
}

And after this query, "ane:QabcdL0001" and "ane:QabcdL0002" will be
added into the "default-nep-map".

You may notice that they use different prefixes ("Qabcd" and "Qabde")
of ane names to ensure there is no same ane name in different
responses. The ALTO server can also adopt other ways to ensure the ane
names are query-specific (which means the ane names in responses of
different queries are not conflict).

Any thoughts?

[0] https://www.ietf.org/id/draft-roome-alto-unified-props-new-00.txt

Jensen

On Wed, Mar 22, 2017 at 9:06 PM, Chan Dawn <[e-mail]> wrote:
> Hi Xin,
>
> Thanks for your comments and I agree with Jensen.
>
> Besides, I would like to point out that if the property map doesn't support
> some property types, all of its network elements is not able to have that
> property. So, in your example,
>
>>"property-map": {
>>          "ne:ne12": { "availbw": "90", "delay": "unknown" },
>>          "ne:ne23": { "availbw": "80", "delay": "15" },
>>          "ne:ne34": { "availbw": "70", "delay": "25" }
>>  }
>
> If property "delay" is not supported, all the network elements shall not
> have the "delay" property, not only the netwrok element "ne:ne12".
>
>
> Another thing is that if the property for a specific network element is not
> available, the property map will return value "null" for that property.
>
>
> Best Regards,
>
> Dawn
>
>
>
> ________________________________
> 发件人: Jensen Zhang <[e-mail]>
> 发送时间: 2017年3月22日 14:35
> 收件人: xin wang
> 抄送: Chan Dawn; [e-mail]; [e-mail]
> 主题: Re: Design issue on path vector
>
> 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