Re: [Lsr] AD Review for draft-ietf-ospf-yang-21

Alvaro Retana <> Thu, 27 June 2019 11:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F3E1120170; Thu, 27 Jun 2019 04:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sI43Z-c-Gp5a; Thu, 27 Jun 2019 04:55:02 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E2EF81200C5; Thu, 27 Jun 2019 04:55:01 -0700 (PDT)
Received: by with SMTP id w13so6834150eds.4; Thu, 27 Jun 2019 04:55:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=PxHnTFhpfOithEtLd4Xzp72cFcgISWTmLOVZ6jJ+1ag=; b=C5JDPUpfZ1pzfI3OrAcVx8KYsGNKZhesvUDJKwqKL7KuCsvp4vRKMlGzIi4iUKFfLY roXt2jOzzpTQkd8M/Jou0KXEV5ucgOWcHhJk0t1aMVJG5BJ/yDje2NsbctbuKRQmk9Xt aTALJ4ZTLyW5lidIou3t602sT5aak/lfx+KFgrqDgNkCo2zkDO3cIZGD5bVy6j9E+9v9 P9O0M47PHgdEuUKdblVQxcd3bHp+ziORxJjidL3jIpTES100xCtRyvvyv6h8ZWgYwpPR f42O1yICSY1Y+DR2M5m7tyv5HUEJQTEoMf3Epgu2x6cTtGXiKKU8EsGpUxINvsOxqGsE XPtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=PxHnTFhpfOithEtLd4Xzp72cFcgISWTmLOVZ6jJ+1ag=; b=DGK2tBs5sPXmmw4QeqhbGt/6OJALiLb5tvqlDZbpr6m5arMGqotzMR+SvIAwytFNze iAKntOrhgKdhrMnGl/HAvq8/QQ6J1Dc3aI5rxAJdjFL6syrqh4qpIauCSZ/1vaj7g8Kw OaUm/25ttHHEgwXCBk/oyHz/Ke6Sw5oWku76UTrtBTf5Hndt5w7SR0/6sZVTOf6cm6Lp PBMIitgirwMJVB8KSpHunb6ZT5xWrb7c/eOSm5XwfEH1mk9aCrvbUnNlVdx3t11Kqq+2 eiK4Rb88h6DkpW4KqW2+Iyh52QkUbwuPBxohKk/dzcziUznThEOb6JumLVaXs9y6ZNry v/FA==
X-Gm-Message-State: APjAAAU+0OwSMUJ+28DgIxc//vzdKK/FSy9pIaN4SDPQnihkl7l8iFTZ UZSAIE9N6TpFQQthpKLjKCeTiwrNzUJt8Bd9RZVStg==
X-Google-Smtp-Source: APXvYqxnZoLuv1idnpbsVY+YJNv1RJLbFFLxivlFe4TB/2eDWvO6bsHO0qpxetJViT/6p7R1EJ88HCo7rd73mDSv1Aw=
X-Received: by 2002:a50:a5ec:: with SMTP id b41mr3562916edc.52.1561636500573; Thu, 27 Jun 2019 04:55:00 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 27 Jun 2019 07:54:59 -0400
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Date: Thu, 27 Jun 2019 07:54:59 -0400
Message-ID: <>
To: "Acee Lindem (acee)" <>, "" <>
Cc: "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000e2926d058c4cd49c"
Archived-At: <>
Subject: Re: [Lsr] AD Review for draft-ietf-ospf-yang-21
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Jun 2019 11:55:04 -0000

On June 26, 2019 at 9:31:05 PM, Acee Lindem (acee) ( wrote:



3936       leaf dead-timer {

3937         type uint32;

3938         units "seconds";

3939         config false;

3940         description "This timer tracks the remaining time before

3941                      the neighbor is declared dead.";

3942       }

[major] For *-timer: Is tracking the remaining time in seconds enough?  I
would assume that ms would be the right unit.  Why seconds?

<acee> Because sub-second hellos was a bad idea – three words: B-F-D…'

This question is not about sub-second Hellos…it’s about the *remaining
time*.  Even if Hellos are x seconds apart, the “remaining time before the
neighbor is declared dead” can still be in ms, right?  Why not?  Note that
there are other places in the model that are characterized as tracking the
remaining time.

I don’t feel that strongly. However, it would seem that one would use the
same granularity as the configuration. No?

I wouldn’t think so.  If I was an operator I would like to know if there
are 500ms left before my neighbor dies, and not just 1 or 0.  I think this
may also be useful for troubleshooting.

But I’m not an operator…


We found that the RFC 8294 timer types aren’t good for “config true” values
since the values “infinity” and “not-set” are included in the union. Hence,
they lend themselves better to operational state than configurable values.