Re: [Idr] Tsvart last call review of draft-ietf-idr-te-pm-bgp-15

"Les Ginsberg (ginsberg)" <> Thu, 13 December 2018 21:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22D1A130EAB; Thu, 13 Dec 2018 13:57:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.96
X-Spam-Status: No, score=-15.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bhbl76Pt7H-7; Thu, 13 Dec 2018 13:57:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D2BC130EA9; Thu, 13 Dec 2018 13:56:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=19264; q=dns/txt; s=iport; t=1544738220; x=1545947820; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EDcZQ/v+xWVDRxduYB+A9C6zsgVJxW3NQEKipJlyty4=; b=K5DVd5vZNBGrDCt74yhyiim2KFmn13DWdFijGDCD269XHNWAEuWZ3LKr jDBFR88x/JsDL/0UpJID3K34FYubxRjGuVnYRR5elaA85FOHDhtp1NkfR Tbxea4IqCndq6qno99AVqgaUmy6QLPZERcx3f80XWTDS1ENARmv7JQFtU s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACi1BJc/5hdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ12ZoECJwqDcogZjBGCDZF6hVqBegs?= =?us-ascii?q?BAYRsAheCbCI0CQ0BAwEBAgEBAm0ohTwBAQEBAgEjCkwFBwQCAQgRBAEBKAM?= =?us-ascii?q?CAgIwFAkIAgQOBQiDGoEcXAioR4EviiqMPBeBQD+BEIMThRgPEIJOglcCiWu?= =?us-ascii?q?BR4N9hlGKOlUJApFPIIFchRyKUpkiAhEUgScfOIFWcBU7gmyQW0ExjCeBHwE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.56,349,1539648000"; d="scan'208,217";a="212275630"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2018 21:56:58 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id wBDLuwnE025274 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Dec 2018 21:56:58 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 13 Dec 2018 15:56:57 -0600
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Thu, 13 Dec 2018 15:56:57 -0600
From: "Les Ginsberg (ginsberg)" <>
To: Yoshifumi Nishida <>
CC: "" <>, "" <>, "" <>, "" <>, "" <>
Thread-Topic: Tsvart last call review of draft-ietf-idr-te-pm-bgp-15
Thread-Index: AQHUksLyuDnkgtzxkU+dPru28q4P+6V85B4wgACLbgD//8aCsA==
Date: Thu, 13 Dec 2018 21:56:57 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9eff1b233b484c9cb6dae8b64dff6d89XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Idr] Tsvart last call review of draft-ietf-idr-te-pm-bgp-15
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Dec 2018 21:57:03 -0000

Yoshi –


From: Yoshifumi Nishida <>
Sent: Thursday, December 13, 2018 11:16 AM
To: Les Ginsberg (ginsberg) <>
Subject: Re: Tsvart last call review of draft-ietf-idr-te-pm-bgp-15

Hi Les,
On Thu, Dec 13, 2018 at 10:13 AM Les Ginsberg (ginsberg) <<>> wrote:
Yoshi -

Thanx for the review.
Replies inline.

> -----Original Message-----
> From: Yoshifumi Nishida <<>>
> Sent: Thursday, December 13, 2018 1:05 AM
> To:<>
> Cc:<>;<>;<>
> Subject: Tsvart last call review of draft-ietf-idr-te-pm-bgp-15
> Reviewer: Yoshifumi Nishida
> Review result: Ready with Nits
> This document has been reviewed as part of the transport area review
> team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the
> discussion list for information.
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
><> if you reply to or forward this review.
> Summary: Ready with Nits
> 1: The TLV formats in the draft look identical with RFC7471 except the value in
> Type field.
>      it would be better to clarify this points so that the readers who are
>      familiar with RFC7471 can interpret them easily. I am also wondering if
>      the format figures of TLV are necessary when the same figures are already
>      presented in RFC7471.

[Les:] The draft says:

Section 2

" TLV formats follow the rules defined in [RFC7752]."

Then in each subsequent sub-section 2.x  both RFC 7471 and draft-ietf-lsr-isis-rfc7810bis are explicitly referenced.

The TLV formats need to be presented here since these are the BGP-LS encodings, which are similar to but NOT identical to the IGP specific encodings (for example IS-IS encoding uses an 8-bit type/length).

Right. But, but in case of OSPF, I think the format will be identical except the type field value.
I just thought if you add one sentence to clarify the formats happen to be the same as 7471, it could be a small benefit for OSPF users.
But, this is not a strong opinion.

[Les:] The format follows RFC7752. It just happens in this case the format for these TLVs matches OSPF – that isn’t always the case. As a practical matter I don’t think it helps implementers to point out when BGP-LS TLVs are identical to protocol X or protocol Y.

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