Delay not available for computation

[carloperocchio]

Questions and answers discussion: Italo Busi, Sergio Belotti, Daniele Ceccarelli, Francesco Lazzeri, Gianmarco Bruno, Carlo Perocchio Monday, December 05, 2016

Q: Delay not available for computation

Context: TE-tunnel issue

R: it should be possible to specifity the delay as one of the MCP. Already in the TE tunnel issues list.

[italobusi]

Italo/Sergio/Ricard:

It is possible to consider delay for te-link-connectivity-attributes (see above) in teas-topology . Not totally clear if that can be reconciled also in tunnel model (see below )

I want a path with delay smaller than X ms or a path with minimum delay?

      |  |  |  |  |  +--ro path-constraints
      |  |  |  |  |  |  +--ro topology-id?       te-types:te-topology-id
      |  |  |  |  |  |  +--ro cost-limit?        uint32
      |  |  |  |  |  |  +--ro hop-limit?         uint8
      |  |  |  |  |  |  +--ro metric-type?       identityref

Minimum delay, you’ll select the metric-type TE to optimize when computing path. Smaller than X msec, then you need to set cost-limit to X.

[efralaz]

This is a workaround suggested to manage delay when the TDB doesn't support the extensions defined in RFC 7471. I believe it's possible to live with this for a while, but it should be better to be future-proof and foreseen these important extensions already.

[efralaz]

Please, consider the draft-ietf-pce-pcep-service-aware-13. It's going to include in PCEP support not only for delay, but also for delay variation and packet loss.

[sergiobelotti]

It has been added in te-tunnel , (te-types): identity path-metric-delay-average { base path-metric-type; description "Unidirectional average link delay"; reference "RFC7471"; }

Is it enough to consider issue closed?

[carloperocchio]

rpc to be updated

[italobusi]

I think the issue is now closed

@carloperocchio : could you please check?