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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 20 December 2018 05:02 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74ED130F99; Wed, 19 Dec 2018 21:02:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.554
X-Spam-Level:
X-Spam-Status: No, score=-14.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 syRtwkZyWPtN; Wed, 19 Dec 2018 21:02:14 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FDF12E043; Wed, 19 Dec 2018 21:02:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21014; q=dns/txt; s=iport; t=1545282134; x=1546491734; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=N8+t4d/Y7CVrgxxDN2XtTU7daNDzS8IBj51jPq/GfxQ=; b=ZkZkJ2MvimAfMjxPeDzF06XLXYvQpiXY9BK68pu9oOPfsw158RRWuVfQ Nq76imxS0oO3UtUVJnIWxw7FdGfqpgI9PMC0ut4hCO/Bm0TkQy4L5IM+y yhEiSSmlEniE1akOOpTM7AqMwap3LXW/P7gm0UHvv5ajrFdPoE6Fz1FLs o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABdIRtc/4kNJK1kDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYENdmaBAicKg3OIGY4JfIgZiG2FWxS?= =?us-ascii?q?BZwsBASOESQIXglQiNAkNAQMBAQIBAQJtHAyFPAEBAQECASMKTAUHBAIBCBE?= =?us-ascii?q?EAQErAgICHxEdCAIEAQ0FCIMbgR1MAw0ID6c2gS+EQUCDAw2CGAWMPxeBQD+?= =?us-ascii?q?BEYJdNYJXRwIBAgGBKgESAYMnglcCiUqBdoQChliKajMJAocOhyGDKSCBXoU?= =?us-ascii?q?filyJSIR6gROKCAIRFIEnHzhlWBEIcBWDJ4InFxKITIUEO0ExAYwogR+BHwE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.56,375,1539648000"; d="scan'208,217";a="497412561"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Dec 2018 05:02:12 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id wBK52Cfx002915 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Dec 2018 05:02:12 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 19 Dec 2018 23:02:11 -0600
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1395.000; Wed, 19 Dec 2018 23:02:11 -0600
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-idr-te-pm-bgp@ietf.org" <draft-ietf-idr-te-pm-bgp@ietf.org>, Susan Hares <shares@ndzh.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "shares@ndzh.com" <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-idr-te-pm-bgp-17: (with DISCUSS and COMMENT)
Thread-Index: AQHUmBH2IC+fkystHEOTj6E4FEK61aWHENkg
Date: Thu, 20 Dec 2018 05:02:11 +0000
Message-ID: <76e889b5707b486ba0bbd7f6ebb054da@XCH-ALN-001.cisco.com>
References: <154527557752.2017.15079929288930486875.idtracker@ietfa.amsl.com>
In-Reply-To: <154527557752.2017.15079929288930486875.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.112.6]
Content-Type: multipart/alternative; boundary="_000_76e889b5707b486ba0bbd7f6ebb054daXCHALN001ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Oj6qFp0I_YGCznpmJt6ncSuDxHY>
Subject: Re: [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
Precedence: list
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 05:02:17 -0000

Ben -



Inline.



> -----Original Message-----

> From: Benjamin Kaduk <kaduk@mit.edu>

> Sent: Wednesday, December 19, 2018 7:13 PM

> To: The IESG <iesg@ietf.org>

> Cc: draft-ietf-idr-te-pm-bgp@ietf.org; Susan Hares <shares@ndzh.com>om>;

> aretana.ietf@gmail.com; idr-chairs@ietf.org; shares@ndzh.com; idr@ietf.org

> Subject: Benjamin Kaduk's Discuss on draft-ietf-idr-te-pm-bgp-17: (with

> DISCUSS and COMMENT)

>

> 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:

> https://datatracker.ietf.org/doc/draft-ietf-idr-te-pm-bgp/

>

>

>

> ----------------------------------------------------------------------

> DISCUSS:

> ----------------------------------------------------------------------

>

> 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.



[Les:] There is no concept of "measurement intervals" here. The BGP-LS advertisements are simply reporting what the IGPs have advertised.

Measurement intervals/delays etc. are all done before the information is given to the IGPs to advertise. This is discussed in the IGP specifications.



Perhaps you will find relevant this exchange between Yoshi and myself in the context of his Tsvart review:



<snip>

> 2: There is no guidance for default values such as measurement interval in

> the

> draft. If these values should also be inherited from other draft, it should be

> stated.

>

[Les:] This is not within the purview of this draft. All this draft is doing is defining the encodings for the BGP-LS advertisements which are essentially copies of what the IGPs are advertising.



Does it mean when an IGP advertises these metrics at 10 sec interval, the BGP-LS will be advertised at the same interval?



[Les:] The IGP RFCs provide significant detail on the importance of controlling the rate of change of advertisements.

Given that, yes – I would expect that updates are provided to BGP whenever the IGP advertisements change.

BGP implementations typically have their own knobs to control the frequency of BGP updates – but given the filtering done at the source I would hope implementations have no need for additional dampening in BGP itself – but that is an implementation choice.



<end snip>



   Les





>

>

> ----------------------------------------------------------------------

> COMMENT:

> ----------------------------------------------------------------------

>

> 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,

> though.

>

>

> 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!

>