Hi Ben,
Thanks for the excellent review - see one inline.
On 10/8/19, 6:13 AM, "Benjamin Kaduk" <ka...@mit.edu> wrote:
Hi Stephane,
Thanks for pulling in the fixes; just a few notes inline (and trimming)...
On Tue, Oct 08, 2019 at 10:33:49AM +0200, slitkows.i...@gmail.com wrote:
> Hi Benjamin,
>
> Thanks for your comment.
> Please find some inline answers.
> I'm doing the changes as part of the -41.
>
>
> Stephane
>
> -----Original Message-----
> From: Benjamin Kaduk via Datatracker <nore...@ietf.org>
> Sent: mercredi 2 octobre 2019 03:17
> To: The IESG <i...@ietf.org>
> Cc: draft-ietf-isis-yang-isis-...@ietf.org; Yingzhen Qu
<yingzhen.i...@gmail.com>; aretana.i...@gmail.com; lsr-cha...@ietf.org;
yingzhen.i...@gmail.com; lsr@ietf.org
> Subject: Benjamin Kaduk's Discuss on draft-ietf-isis-yang-isis-cfg-40:
(with DISCUSS and COMMENT)
>
[...]
>
>
> In the "protection-available" container, is there some sort of constraint
that two of the alternate-metrics add up to the third?
> [SLI] It is not really a constraint from a YANG point of view, these are
operational counters.
Sorry, I shouldn't have used the word "constraint", since that's a YANG
verb. I was just asking if the description should reiterate to the reader
that in normal circumstances the two will add up to the third (and "no" is
a fine answer).
[...]
> container delay-metric {
> leaf metric {
> type std-metric;
> description "IS-IS delay metric for IPv4 prefix";
> }
> leaf supported {
> type boolean;
>
> Should the "metric" leaf be conditional on "supported" being true?
> (Same for the other flavors of metric, as well as when they appear later
on in the "neighbor" grouping.)
>
>
> [SLI] This is not a configuration leaf, so I don't think that there is a
need for enforcement at YANG level.
Oh, I had missed that it was config false; sorry about that.
[...]
>
> container unidirectional-link-delay-variation {
> description
> "Container for the average delay variation
> from the local neighbor to the remote one.";
> leaf value {
> type uint32;
> units usec;
> description
> "Delay variation value expressed in microseconds.";
>
> Is this a standard deviation (variance), mean absolute error, ...?
> [SLI] We just mimic what is defined in RFC8570. As the reference is
defined in the model. People should refer to it for more details.
> Moreover this is a pure operational state.
https://tools.ietf.org/html/rfc8570#section-4.3 still leaves me a little
unclear about what exactly is being reported (it sounds like it's just an
average link delay so the word "variation" confuses me), but I agree that
we should not say any more in this document.
> container unidirectional-link-loss {
> [...]
> leaf value {
> type uint32;
> units percent;
> description
> "Link packet loss expressed as a percentage
> of the total traffic sent over a configurable interval.";
>
> This document is all about specifying configuration. How do I configure
the interval in question?
> [SLI] This is an operational state.
The leaf value is operational state, yes, but it reports a valid computed
"over a configurable interval". How do I configure that interval?
I don't disagree that there is more configuration and state associated with
these traffic metrics. However, these are not really under the purview of this
model since IS-IS (and OSPF for that matter) are only serving as a mechanism to
advertise these traffic metrics.
Thanks,
Acee
Thanks!
-Ben
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
