Re: [RTG-DIR] Rtgdir last call review of draft-ietf-idr-rfc7752bis-11
Ketan Talaulikar <ketant.ietf@gmail.com> Mon, 07 November 2022 13:20 UTC
Return-Path: <ketant.ietf@gmail.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 8E0E0C1524CD; Mon, 7 Nov 2022 05:20:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Nqvn5VHAUVN0; Mon, 7 Nov 2022 05:20:08 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5123C1524DD; Mon, 7 Nov 2022 05:20:07 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id a15so16191443ljb.7; Mon, 07 Nov 2022 05:20:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nlJyD5COl9LNLjeVhqkLJKZ+ZFE9lsAU8XI4chaMoi4=; b=kl6iGINS6kFfzyHGBa9gldYn622s8kkoR3H1QJKkPrLmJ1J6IRBmGt3js5hMcdEgbf CybB6cnSEhFxk73bsWDUA7h4WeI7RHyPR6DUe6c7JstFEUbzY21JOEnTxiSy74dclHwI cB8hGlR+bjQkvgZ3FHEqzUx1nXOiJS9TeMUTMBMDkekomiDqczeCeN9J5E2KzgNOWlNP cYeFHBHm2udry4ryVmTBC3ZvH0IE4eiiqiHbSzqpumCNpmam8Z6VJ+bPDLX5+R7zWfyY ciGNBYXFkzxvMK05aayNk0v364zUrMv/I3gsYh9WoGqRcwQdp4SSWJg0K6dRfHI69x3P +Kyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nlJyD5COl9LNLjeVhqkLJKZ+ZFE9lsAU8XI4chaMoi4=; b=hCUYuVYa7wtTKHxj2h3JeV9vgtgUvdbeRj7Njah7PXuPN2/Ab92RMTpBtAJM9iz2qA KnZbpIGGx5wlaOAioSPXa1TxdKCvli2oISBarEyn5sr4tAOpv6e9uuGg706XMWUMJTD8 jBLaeSynvjnkUvPzT2gpYo0aU+fNH5BGyH63fXvvsm6U5asvMc3RRp5rM92oY4PgInJl n9lmrsPbppOgj1RZ9GWiNvEWkongxwU86+MBIoVUXlbMtXJlfV+nA2j0XzrljF80JxL4 FY85aHfhTa6aYMyZsDWlesQdNlzD4eN7x6FKDB9Uit2+4JdfpB+0bJ05SOOIxI3YCg9d Y2ww==
X-Gm-Message-State: ANoB5pk8sK1ga0yBNsSFRmotZI+v1Ut/LHHZr/5ZEMVkVcTGbSS/Ysi9 ecUetJTvzAugyrg89tK/cB5OQRa8AYNTsT8YVW33BiSD
X-Google-Smtp-Source: AA0mqf4zADqqZpSDBCEhOTNjzk+EqPGenWluVnjXso2o3TaeHqrLcVup727XVGiL0fWvUuEEqZe6oHJuwXT14F8MywU=
X-Received: by 2002:a2e:9ed6:0:b0:277:9689:22aa with SMTP id h22-20020a2e9ed6000000b00277968922aamr4451606ljk.359.1667827206001; Mon, 07 Nov 2022 05:20:06 -0800 (PST)
MIME-Version: 1.0
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> <267fc91d-1025-f7c0-2829-60cce7af9740@joelhalpern.com>
In-Reply-To: <267fc91d-1025-f7c0-2829-60cce7af9740@joelhalpern.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Mon, 07 Nov 2022 18:49:53 +0530
Message-ID: <CAH6gdPwstJKEnZT8agVedTA2K+jXyH1YNdVxOE0S8Jxn67L-ww@mail.gmail.com>
To: Joel Halpern <jmh@joelhalpern.com>
Cc: rtg-dir@ietf.org, draft-ietf-idr-rfc7752bis.all@ietf.org, idr@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="00000000000029171305ece148d0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/T912p9tC6PJDD5ER3fQ0ced9_G8>
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 13:20:12 -0000
Hi Joel, Thanks for confirming. I have these changes in the edit buffer to be included in the next update. Thanks, Ketan On Mon, Nov 7, 2022 at 6:22 PM Joel Halpern <jmh@joelhalpern.com> wrote: > 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