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

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

Return-Path: <ginsberg@cisco.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D1A130EAB; Thu, 13 Dec 2018 13:57:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.96
X-Spam-Level:
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: 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 Bhbl76Pt7H-7; Thu, 13 Dec 2018 13:57:00 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D2BC130EA9; Thu, 13 Dec 2018 13:56:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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 rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2018 21:56:58 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-1.cisco.com (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 xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 13 Dec 2018 15:56:57 -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; Thu, 13 Dec 2018 15:56:57 -0600
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
CC: "nishida@wide.ad.jp" <nishida@wide.ad.jp>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-idr-te-pm-bgp.all@ietf.org" <draft-ietf-idr-te-pm-bgp.all@ietf.org>
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: <9eff1b233b484c9cb6dae8b64dff6d89@XCH-ALN-001.cisco.com>
References: <154469190410.2732.7123292408392294701@ietfa.amsl.com> <d07090284c9f46f48c5d479297b4a865@XCH-ALN-001.cisco.com> <CAO249yd5v3pDuOgLqmVsp2yr+zfXWJyvSx6b67kM21Tusza7DQ@mail.gmail.com>
In-Reply-To: <CAO249yd5v3pDuOgLqmVsp2yr+zfXWJyvSx6b67kM21Tusza7DQ@mail.gmail.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.104.232]
Content-Type: multipart/alternative; boundary="_000_9eff1b233b484c9cb6dae8b64dff6d89XCHALN001ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/mfTOR2cafXQgs-Bkd5QlUvOotZ8>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-idr-te-pm-bgp-15
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Dec 2018 21:57:03 -0000

Yoshi –

Inline.

From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>;
Sent: Thursday, December 13, 2018 11:16 AM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>;
Cc: nishida@wide.ad.jp; tsv-art@ietf.org; idr@ietf.org; ietf@ietf.org; draft-ietf-idr-te-pm-bgp.all@ietf.org
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) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> wrote:
Yoshi -

Thanx for the review.
Replies inline.

> -----Original Message-----
> From: Yoshifumi Nishida <nishida@wide.ad.jp<mailto:nishida@wide.ad.jp>>
> Sent: Thursday, December 13, 2018 1:05 AM
> To: tsv-art@ietf.org<mailto:tsv-art@ietf.org>
> Cc: idr@ietf.org<mailto:idr@ietf.org>; ietf@ietf.org<mailto:ietf@ietf.org>; draft-ietf-idr-te-pm-bgp.all@ietf.org<mailto:draft-ietf-idr-te-pm-bgp.all@ietf.org>
> 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
> IETF
> 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
> tsv-art@ietf.org<mailto:tsv-art@ietf.org> 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.

  Les

Thanks,
--
Yoshi