Use path loss and delay variation metrics as metrics for optimization

[oscargdd]

In current model, when computing a path, an optimization metric can be set. The optimization metrics are those of base type path-metric-type:

• TE path metric
• IGP path metric
• Hop path metric
• Unidirectional average link delay
• Unidirectional minimum link delay
• Path-metric-residual-bandwidth
• path-metric-optimize-includes
• path-metric-optimize-excludes
  We would need to support aditionally, at least, the metrics that are available in PCEP, in particular, those defined in RFC 8233
• delay variation (defined in RFC 7471).
• path losss (defined in RFC 7471).
  Currently, those metrics are defined in te-types as performance metrics and are used in the te-mpls model, however, not to be used in the optimization.

I agree, these should be added. Should be supported both as optimization metrics and as path constraints with upper-bound.

[tsaad-dev]

@jkarvone: selecting optimization metric and setting metric is currently possible. See:

container path-metric-bounds {
  description
    "TE path metric bounds container.";
  list path-metric-bound {
    key "metric-type";
    description
      "List of TE path metric bounds.";
    leaf metric-type {
      type identityref {
        base path-metric-type;
      }
      description
        "Identifies an entry in the list of 'metric-type' items
         bound for the TE path.";
    }
    leaf upper-bound {
      type uint64;
      default "0";
      description
        "Upper bound on the end-to-end TE path metric.  A zero
         indicates an unbounded upper limit for the specific
         'metric-type'.";
    }

@oscargdd: from RFC 8233:

    Value       Description                        Reference
    ----------------------------------------------------------
    12          Path Delay metric                  RFC 8233
    13          Path Delay Variation metric        RFC 8233
    14          Path Loss metric                   RFC 8233
    15          P2MP Path Delay metric             RFC 8233
    16          P2MP Path Delay variation metric   RFC 8233
    17          P2MP Path Loss metric              RFC 8233

We are missing identity for TE metric-type 13 and 14. These are normally packet specific, so should be added to TE packet types.

[tsaad-dev]

AI (Tarek): to fix this.
Add metric type for path loss
Add metric type for path loss variation

[italobusi]

2020-09-25 TEAS Call
Should this identity be moved to a packet specific module?

[italobusi]

This metric is defined as a percentage but the upper bound is defined as a uint64. Some clarification on how the percentage should be encoded in uint26 is needed.

[tsaad-dev]

uint64 can still be used but the interger is multiplied by the basic unit 0.000003%. This is described in rfc7810#section-4.4

Link Loss: This 24-bit field carries link packet loss as a percentage
of the total traffic sent over a configurable interval. The basic
unit is 0.000003%, where (2^24 - 2) is 50.331642%.

[tsaad-dev]

To add in description

[italobusi]

@tsaad-dev : I have re-opened this issue to track the two comments discussed during 2021-05-21 TEAS call:

• e23b295#r51130614
• e23b295#r51130821