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

Jeffrey Haas <jhaas@pfrc.org> Mon, 01 July 2019 20:06 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D901200E7; Mon, 1 Jul 2019 13:06:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjAd3bBEDaKe; Mon, 1 Jul 2019 13:06:20 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 08ED01200E0; Mon, 1 Jul 2019 13:06:19 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 08E121E2F1; Mon, 1 Jul 2019 16:07:43 -0400 (EDT)
Date: Mon, 1 Jul 2019 16:07:42 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, "Acee Lindem (acee)" <acee@cisco.com>, "draft-ietf-ospf-yang@ietf.org" <draft-ietf-ospf-yang@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>
Message-ID: <20190701200742.GB30898@pfrc.org>
References: <CAMMESsztO1a4fnT2Gx2GDKcYVLtWS52WZ=HmPdQ9VFqSEtvG7Q@mail.gmail.com> <77F1A67E-2EB8-453E-8E89-70C55A820E03@cisco.com> <CAMMESsxq4dAvGn0n30NnpbygLf13j5uWK6=6feqNJsMDuzuUrQ@mail.gmail.com> <898A5C23-D95A-4CED-B99A-9881C95D236B@cisco.com> <CAMMESsx+KXmQJth+OKBrUkrSoMMuYH=Lk755a7tw0qGwpB6sWQ@mail.gmail.com> <B5FAB592-D74E-44FB-85AF-227AB3FDD2AC@cisco.com> <CAMMESsxumpAV4jR1qhwb-ofywRbj-GtwAVGBiSgm6panrGsQDw@mail.gmail.com> <BYAPR11MB363848AE1ECAF545881723B8C1FD0@BYAPR11MB3638.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <BYAPR11MB363848AE1ECAF545881723B8C1FD0@BYAPR11MB3638.namprd11.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/0vgwgLnijaV2dA2wHmOBH6NlR2c>
Subject: Re: [Lsr] AD Review for draft-ietf-ospf-yang-21
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jul 2019 20:06:22 -0000

On Thu, Jun 27, 2019 at 03:11:21PM +0000, Les Ginsberg (ginsberg) wrote:
> I am firmly on the side of Acee on this one – and I think more attention needs to be paid to his initial answer: “B-F-D”.
> 
> The implications of this are that we do not expect control plane to have finer granularity than seconds – which is why routing protocol hold times are expressed in seconds (both adjacency hold times and LSA hold times).
> Which means that even if you had the ability to display “X.mmm seconds remaining” this would not mean that the actual reaction to the timeout would occur within milliseconds of the timer expiration.
> 
> I would also argue that operationally it does not matter if an adjacency times out in N seconds or N.5 seconds. This is not used as a fast failure detection mechanism.

I agree for a slightly different reason:
In general, if your protocol is concerned with second level granularity,
that's what should be presented at the management level.  

Not to mention let's not make all sorts of implementations have to go put in
a float to track what's probably been storing an integer for years.

-- Jeff