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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Fri, 14 December 2018 22:42 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 6F31B13133D; Fri, 14 Dec 2018 14:42:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.958
X-Spam-Level:
X-Spam-Status: No, score=-15.958 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, 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, 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 U4YG5-cGoQDW; Fri, 14 Dec 2018 14:42:55 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56DE130EF2; Fri, 14 Dec 2018 14:42:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26486; q=dns/txt; s=iport; t=1544827375; x=1546036975; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=creIyzz5BZichhyJmw011J9PTXo8jTWATuyfyX+P6kM=; b=Vnx19F6k8PaQx1yVGkcRbCmDOmYxcCnQDbuBJTAnJpCdL94otpGONSqw CsQP6C1/k7xdJcU++/5P+5rQKCX8nRcxXaCv0a0ZQLd+ris5s1PPlCdS3 fIy6mUEqaDCbvGSN17ZIMMauR8Xw7/jFQpvUqwTkC2dSPL+wUKvTaeIy9 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACvMBRc/5JdJa1aChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYENdmaBAicKg3KIGYt4gg18iBiOQ4F?= =?us-ascii?q?6CwEBJYRHAheCbiI0CQ0BAwEBAgEBAm0cDIU8AQEBAQMjCkUHEAIBCA4DBAE?= =?us-ascii?q?BIQcDAgICHxEUCQgCBAENBQgXgwOBHEwDFQ+mDoEviAENghcFjD4XgUA/gRG?= =?us-ascii?q?CXTWCV0cBAQIBgTNhglCCVwKLNoN+hlOKYi8JAocLhx2DKCCBXY91iTuBBYN?= =?us-ascii?q?xgRKJdwIRFIEnHziBVnAVgyeLHIU/QTEBjRWBHwEB?=
X-IronPort-AV: E=Sophos;i="5.56,354,1539648000"; d="scan'208,217";a="212802680"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2018 22:42:53 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id wBEMgro1022165 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Dec 2018 22:42:53 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 14 Dec 2018 16:42:52 -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; Fri, 14 Dec 2018 16:42:52 -0600
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, Susan Hares <shares@ndzh.com>, Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
CC: "draft-ietf-idr-te-pm-bgp.all@ietf.org" <draft-ietf-idr-te-pm-bgp.all@ietf.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "nishida@wide.ad.jp" <nishida@wide.ad.jp>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: Tsvart last call review of draft-ietf-idr-te-pm-bgp-15
Thread-Index: AQHUksLyuDnkgtzxkU+dPru28q4P+6V85B4wgACLbgD//8aCsIABgWIAgAAz4AD//+lnsA==
Date: Fri, 14 Dec 2018 22:42:52 +0000
Message-ID: <5a7601709d714dcf8b1ff6e82d8ade80@XCH-ALN-001.cisco.com>
References: <154469190410.2732.7123292408392294701@ietfa.amsl.com> <d07090284c9f46f48c5d479297b4a865@XCH-ALN-001.cisco.com> <CAO249yd5v3pDuOgLqmVsp2yr+zfXWJyvSx6b67kM21Tusza7DQ@mail.gmail.com> <9eff1b233b484c9cb6dae8b64dff6d89@XCH-ALN-001.cisco.com> <006a01d493bc$31912ec0$94b38c40$@ndzh.com> <CAMMESswwkKCQohdw65RYhDy1nWUr3CYW3FDAZhkevKyHrDO7AA@mail.gmail.com>
In-Reply-To: <CAMMESswwkKCQohdw65RYhDy1nWUr3CYW3FDAZhkevKyHrDO7AA@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_5a7601709d714dcf8b1ff6e82d8ade80XCHALN001ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/afaJ3L_UX4qvTYzFvF8EqviFKe0>
Subject: Re: [Idr] Tsvart last call review of draft-ietf-idr-te-pm-bgp-15
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: Fri, 14 Dec 2018 22:42:58 -0000

Alvaro (and everyone) - -

I have posted V17 which includes the mapping table suggested by Alvaro.

I apologize in advance – but I find the mindset here flawed.

The names given to the parameters are identical in the BGP-LS draft to the ones used in the referenced IGP drafts. I would think that is sufficient to unambiguously identify the relationship between the two. And it has the advantage that it is a symbolic reference – which means that if (however unlikely) the actual codepoint for one of the IGP advertisements were to change, that instead of being able to address this by updating one document – we now have to update both the referencing document(s) and the referenced document. And why do we do this? Because we think that someone who is actually interested in the topic enough to look at both documents won’t be able to easily map between the two???

Sorry, I am shaking my head at this one…and I only take the time to say this in the hope that the collective mindset will change for future documents.

But it is done.

   Les


From: Alvaro Retana <aretana.ietf@gmail.com>
Sent: Friday, December 14, 2018 9:55 AM
To: Susan Hares <shares@ndzh.com>om>; Les Ginsberg (ginsberg) <ginsberg@cisco.com>om>; Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Cc: draft-ietf-idr-te-pm-bgp.all@ietf.org; tsv-art@ietf.org; idr@ietf.org; nishida@wide.ad.jp; ietf@ietf.org
Subject: RE: Tsvart last call review of draft-ietf-idr-te-pm-bgp-15

On December 14, 2018 at 9:49:28 AM, Susan Hares (shares@ndzh.com<mailto:shares@ndzh.com>) wrote:

Sue:

Hi!

I think we might be talking about two different things…or I got lost, which is completely possible. :-)

I think Yoshi is asking about the format of the TLVs, which happens to be the same as the OSPF ones (rfc7471), but slightly different than ISIS (rfc7810bis): the type and length fields are different.  I had already pointed this out in my AD review, so the text changed from "The semantic of the TLV is described in [RFC7810] and [RFC7471]” (in -14) to "The semantics of the value field in the TLV are described in [I-D.ietf-lsr-isis-rfc7810bis] and [RFC7471]” (in -15)…and the text about "TLV formats follow the rules defined in [RFC7752]” was added, as Les pointed out.  I think this is enough.

When you say "align with IGP TLVs”, are you talking about the format of the TLV, or are you referring to something else?

In some BGP-LS document I’ve seen tables that map the BGP-LS TLVs to the corresponding ISIS/OSPF TLVs — with the understanding that the format is different.  One such example is in §2.4/2.5 of draft-ietf-idr-bgp-ls-segment-routing-ext [1].  Is that the alignment you’re asking about?  If so, then I think that such a table would be useful.

Thanks!

Alvaro.


[1] https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-11#section-2.4



You both raised two sides of the issue regarding the BGP-LS TLVs when these TLVs align with IGP TLVs.

Side 1: It is helpful to note that the TLVs are the same
Side 2: It is confusing to have this information in individual drafts.

This is not a single draft issue but a concern regarding several drafts in the BGP-LS series from IDR.

Yoshi -  Would it help the clarity of the BGP-LS series to have an explanatory draft that indicates the places to find the alignment?  Or should we suggest a note to IANA registration to provide clarity.

Thank you for raising both sides of this issue.   Your IDR chairs and AD have been discussing how to make this easier to understand for implementers and those who deploy the BGP-LS code.