[Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-te-pm-bgp-17: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 20 December 2018 03:12 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 836A2130E30; Wed, 19 Dec 2018 19:12:57 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-idr-te-pm-bgp@ietf.org, Susan Hares <shares@ndzh.com>, aretana.ietf@gmail.com, idr-chairs@ietf.org, shares@ndzh.com, idr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154527557752.2017.15079929288930486875.idtracker@ietfa.amsl.com>
Date: Wed, 19 Dec 2018 19:12:57 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ANWEASS9NjymtMJGLQIYIieR6AA>
Subject: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-te-pm-bgp-17: (with DISCUSS and COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Dec 2018 03:13:02 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-idr-te-pm-bgp-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


How are the measurement interval(s) for these TLVs chosen?  I note that RFC
7810 (and 7810bis), as well as RFC 7471, include some text about
measurement intervals, in particular, a default value of 30 seconds and in
at least one case a requirement for configurability at sub-TLV granularity
(thus, TLV granularity for us here).  That said, it's not entirely clear to me whether
I'm supposed to treat the measurement intervals as also inherited from 7810bis/7471
as part of the "semantics of the value field".  It may be worth a brief clarifying note
in the top-level Section 2.


I will be interested to see what the RFC Editor thinks about "the semantics
[...] are described in [I-D.ietf-lsr-isis-rfc7810bis] and [RFC7471]", i.e.,
with both references containing the same content.  It's unclear that we
need to have a conversation about the apparent duplication at this point,

This is pretty clearly looking at the barn door when the horse is long
gone, but the referenced semantics talk about setting the A bit for when
one or more measured values "exceed a configiured maximum threshold", text
that seems to apply even to the field "min delay".  Is the "exceeds"
supposed to interpreted as "outside the expected range, whether that is
numerically larger or smaller than the threshold value"?

Section 2.8

Would it help anyone to have the TLV tag values defined in this document
in the table as well?

Section 3

Thank you for adding the extra text recommended by the secdir reviewer!