Preparation for v08 of RFC8776-bis#252
Conversation
Updated TE packet types module description: fix tsaad-dev#250
Added support for (full) LSP re-routing: see tsaad-dev#243 - obsoleted identity lsp-protection-reroute-extra; - obsoleted identity lsp-protection-reroute; - added identity restoration-scheme-rerouting.
Updated path metric types: see tsaad-dev#103: - moved identity path-metric-loss from ietf-te-mpls to ietf-te-packet-types; - added identity path-metric-delay-varation to ietf-te-packet-types. Few doubts raised in tsaad-dev#103 (comment)
Clarify that derived identities from path-metric-type should describe the unit and maximum value of the associated path metric: see tsaad-dev#103
italobusi
changed the title
| base restoration-scheme-type; | ||
| description | ||
| "Restoration LSP is computed after the failure detection. | ||
|
|
There was a problem hiding this comment.
Having empty lines between different paragraphs in the description is usually easier to read
| description | ||
| "The path delay variation encodes the sum of the unidirectional | ||
| delay variation metrics of all links traversed by a P2P path. | ||
|
|
There was a problem hiding this comment.
I'm not sure the above statement is correct. "The path delay variation is not sum of individual delay variation".
There was a problem hiding this comment.
We may want to use delay variation (DV) as a bound on per link DV.. So, computation can prune links that exceeds the DV bound?
There was a problem hiding this comment.
This is the definition I have found in RFC8233
| base path-metric-type; | ||
| description | ||
| "The path loss (as a packet percentage) metric type | ||
| encodes a function of the unidirectional loss metrics of all |
There was a problem hiding this comment.
can loss be used as a bound? e.g. to prune links that exceed loss of 5%?
There was a problem hiding this comment.
My understanding is that in the ietf-te this is used as a path-metric and not as a link-metric ...
| // CHANGE NOTE: The identity path-metric-loss below has | ||
| // been added in this module revision | ||
| // RFC Editor: remove the note above and this note | ||
| identity path-metric-loss { |
There was a problem hiding this comment.
thinking a bit, why do we want to prepend "path-" to metric type?
Ideally, it is simply metric-type and this can be per link or per path metric type.
There are cases were we can set a bound applicable on per link (e.g. loss, DV, etc.) and other cases where metric is end-to-end.. I'd think where the metric leaf is will tell if per link or per path.
What do you think?
There was a problem hiding this comment.
I agree with you, but I am a bit worried about the side effects
RFC8776 has already defined the base identity as path-metric-type and used this naming convention for the derived identities
Also ietf-te is using these metric types for path metric bound and cumulative values
Added support also for 16 octects TE identifiers (formatted as IPv6 addresses): fix tsaad-dev#129
Container explicit-route-objects-always renamed as explicit-route-objects: fix tsaad-dev#254
3 participants
Updated TE packet types module description: fix #250
Updated TE packet types to support (full) LSP re-routing: see #243
Updated path metric types: see #103:
Updated typedef te-node-id to add support also for 16 octects TE identifiers (formatted as IPv6 addresses): fix #129
Container explicit-route-objects-always renamed as explicit-route-objects: fix #254