Re: [alto] Design issue on path vector

[xin wang <[e-mail]>]

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

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