Missing returned metrics

[efralaz]

PCEP protocol in RFC5440 includes a set of flags for each metric of the METRIC object.
One of these flags is the "C" flag : COMPUTED METRIC, which indicates that PCE must return the value of the given metric in the reply including the computed path.

    “C (Computed Metric - 1 bit): When set in a PCReq message, this 
     indicates that the PCE MUST provide the computed path metric
     value (should a path satisfying the constraints be found) in
     the PCRep message for the corresponding metric.”

This feature is essential for using a stateless path computation, where the metrics returned by a path computation requested to a given PNC must be used by the requesting MDSC to compute the best end-to-end path. If it's missing the MDSC cannot know which is the best e2e path. It's therefore proposed to define a way to request and return the metrics computed by the path computation. A grouping including the metrics to be returned is envisaged, like in the following YANG fragment, which could be part of te-types :

 grouping ReturnedMetrics {
       list _returnedMetrics {
             key 'metric-type';
             leaf metric-type {
                   type identityref {
                         base te-types:path-metric-type;
                   }
             },
             leaf metric-value {
                   description “the computed value”;
                   type uint64;
             }
       }
       description "List of (requested to be) returned metrics";
 }

In the request the optional leaf metric-value shan't be included, as only the list of the requested metrics is needed. In the response, the metric-value shall be populated with the values computed for the returned path. A possible insertion point of the new grouping:

grouping PathComputationService {
  leaf-list _path-ref {
    type leafref {
      path '/paths/path/path-id';
    }
    config false;
    description "List of previously computed path references.";
  }
  container _servicePort {
    uses PathCompServicePort;
    description "Path Computation Service Port.";
  }
  uses te-types:generic-path-constraints;
  uses te-types:generic-path-optimization;
  uses te-types:ReturnedMetrics; // <-- HERE 

  description "Path computation service.";
}

[italobusi]

@efralaz : please submit the proposed updated YANG model via pull request

[efralaz]

Done. The modification is all in ietf-te-path-computation.yang. I prefer not to include the new grouping in te-types as I believe is useless outside stateless path computation.

[italobusi]

I understand that the modifications have been proposed using the pull request #33

[sergiobelotti]

The issue can be closed since related to pull request #33