Re: [RTG-DIR] Rtgdir last call review of draft-ietf-idr-rfc7752bis-11
Joel Halpern <jmh@joelhalpern.com> Mon, 07 November 2022 12:52 UTC
Return-Path: <jmh@joelhalpern.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B6DC1524A2; Mon, 7 Nov 2022 04:52:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.807
X-Spam-Level:
X-Spam-Status: No, score=-2.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UyX4BlDAAEf; Mon, 7 Nov 2022 04:52:45 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5652FC1522CF; Mon, 7 Nov 2022 04:52:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4N5WNY22ykz6GrKR; Mon, 7 Nov 2022 04:52:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1667825565; bh=15aCVKYHmap5mkC6uUaytduzNrQ3EoZEGeMbUYOH1aI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=L2GKYl4BjNLW4hRy3D/uGD0Mm0LEhcjdEqWFVCHWZW+0KrYRL4jvcWRoNl+oGWpSt ICgzNzi9nLaMqPOMQvV1oZwMtw9i0n6VaLWo1pawRa5f/fZjycKyM0hEW/3IYwcNRt jEqH7egATrEvNRN5o5Vnwn2CP7jxw+BwQcp1LKnA=
X-Quarantine-ID: <qWJnXwmrFsGj>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [IPV6:2001:67c:370:128:d567:860e:8447:3401] (unknown [IPv6:2001:67c:370:128:d567:860e:8447:3401]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4N5WNW50mJz6G96L; Mon, 7 Nov 2022 04:52:43 -0800 (PST)
Content-Type: multipart/alternative; boundary="------------brRbhqYNatMjnwa8YAAAvXqA"
Message-ID: <267fc91d-1025-f7c0-2829-60cce7af9740@joelhalpern.com>
Date: Mon, 07 Nov 2022 07:52:42 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1
Content-Language: en-US
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: rtg-dir@ietf.org, draft-ietf-idr-rfc7752bis.all@ietf.org, idr@ietf.org, last-call@ietf.org
References: <166687930912.48245.7099679165950186076@ietfa.amsl.com> <CAH6gdPxHvCN4N29CCWHw8XqLqZmQSpJxibyBNbNBZ_LiLfXmmg@mail.gmail.com> <2e83b437-2cf1-6d37-d84f-78d8eded1264@joelhalpern.com> <CAH6gdPy7KjhX0vn_y7aqeM=37yykZKcBLKmO0av=fWC9LosxiA@mail.gmail.com>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <CAH6gdPy7KjhX0vn_y7aqeM=37yykZKcBLKmO0av=fWC9LosxiA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/8-F-193IuLXkHKUSi0ziLY4kQIQ>
Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-idr-rfc7752bis-11
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Nov 2022 12:52:49 -0000
Thanks. Both those fixes work for me. Yours, Joel On 11/7/2022 7:50 AM, Ketan Talaulikar wrote: > Hi Joel > > Please check inline below for responses with KT2. > > On Mon, Nov 7, 2022 at 4:58 PM Joel Halpern <jmh@joelhalpern.com> wrote: > > Slightly trimmed, two comments. Joel > > > On 11/7/2022 1:03 AM, Ketan Talaulikar wrote: >> Hi Joel, >> >> Thanks for your review and please check inline below for responses. >> >> On Thu, Oct 27, 2022 at 7:32 PM Joel Halpern via Datatracker >> <noreply@ietf.org> wrote: >> >> .. >> None >> >> Nits: >> At the end of the first paragraph of section 4, could we >> add a sentence >> saying "the BGP-LS attributes appear within the >> corresponding new BGP NLRI" >> or similar? While that is explained later in section 4, >> the length of the >> section means that a new reader is left wondering for quite >> some time. >> >> >> KT> The BGP-LS Attribute TLVs do not appear within the NLRI. Sec >> 4.2 introduces BGP-LS NLRIs and indicates that they are carried >> within the MP_REACH/UNREACH. Further Sec 4.3 introduces the >> BGP-LS Attribute and indicates that they are carried as part of >> the BGP update along with the Link State NLRIs (and other >> attributes). Perhaps we can clarify a bit upfront that the new >> NLRI types are carried in the MP_REACH/UNREACH? > > <jmh> Apparently I still managed to misread it. Sorry. It would > help if you could put a little more context at the front of > section 4. </jmh> > > > KT2> How about the following? > > The link-state information is carried in BGP UPDATE messages as: > (1) BGP NLRI information carried within MP_REACH_NLRI and > MP_UNREACH_NLRI attributes that describes link, node, or > prefix object, and (2) a new BGP path attribute (BGP-LS > Attribute) that carries properties of the link, node, or > prefix objects such as the link and prefix metric or > auxiliary Router-IDs of nodes, etc.. > > >> >> Section 4.1 has the paragraph: >> All TLVs within the NLRI that are not specified as >> mandatory are >> considered optional. All TLVs within the BGP-LS Attribute are >> considered optional unless specified otherwise. >> As far as I can tell, those two sentences are saying, about >> two different >> aspects of the encoding, the same thing. But they say it >> in different ways. >> If there is some subtle difference in meaning taht is >> intended, please >> clarify. If the meaning is indeed the same, could we use >> parallel >> construction to avoid readers thinking there is a difference? >> >> >> KT> They are talking about two different "containers" - the NLRI >> and the BGP-LS Attribute. The "default" is different for them. > <jmh>I am having trouble parsing the distinction, even if the > external default is different. The two sentences both seem to say > that the only mandatory items are those which are specified as > mandatory. They simply say it in two different ways. Why is the > sentence construction different? If there is an actual difference > in intended effect, I think a few more words would be helpful. </jmh> > > > KT2> How about the following? > For both the NLRI and BGP-LS Attribute parts, all TLVs are > considered as optional except where explicitly specified as > mandatory or required in specific conditions. > Thanks, > Ketan > >> >> Thanks, >> Ketan >>
- [RTG-DIR] Rtgdir last call review of draft-ietf-i… Joel Halpern via Datatracker
- Re: [RTG-DIR] Rtgdir last call review of draft-ie… Ketan Talaulikar
- Re: [RTG-DIR] Rtgdir last call review of draft-ie… Joel Halpern
- Re: [RTG-DIR] Rtgdir last call review of draft-ie… Ketan Talaulikar
- Re: [RTG-DIR] Rtgdir last call review of draft-ie… Joel Halpern
- Re: [RTG-DIR] Rtgdir last call review of draft-ie… Ketan Talaulikar