Re: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01

Pushpasis Sarkar <pushpasis.ietf@gmail.com> Tue, 25 July 2017 13:31 UTC

Return-Path: <pushpasis.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 C3684131C33; Tue, 25 Jul 2017 06:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVdCD590mHqw; Tue, 25 Jul 2017 06:31:32 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C6B131CB7; Tue, 25 Jul 2017 06:31:32 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id l82so10973204ywc.2; Tue, 25 Jul 2017 06:31:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7EciIS7eumFKMjHy96Lu7flwsMubWv5AIIoZFgYskW8=; b=GxEhfV+Eov67DMzesFAYWWnSqqxI1GNLt5+84ztMp0gbHwkciVTGAQrJc+8Sh0eOmI c+vkzgZuDrJyaKTWDZ4L6tK22Y7HLgjt4oGQL/IJ3A2UgNycg77vRDvVYov9SJmsdnbY XNH5qMczBGDZ23wmoCS19BFDHqNkBNEVzj/046yvB5IL9kgg+qm57o291HuvXL+YUlhz PAJZWaIsKREK9jb6yMjvdf8p/THTD5HcHFhwt9Uaar1pedijTBrM8wE5SKtthcRYaAx5 w6r8uTAGu3IumHUpqUTBJ2A7i8unTcd1qfOM9+yradlwtwBCLrE+taU8DqbmBNCQ2axf WYbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7EciIS7eumFKMjHy96Lu7flwsMubWv5AIIoZFgYskW8=; b=iNHUyS+BwGp0j561Pm74UiTv1J0hGf2O8lykZwY+Z85Ge7DxZu+B7yPyt1MjO+PmOq v+e0K4Ch2pds8B2N9/jZ+n7YI4tvSS4pAvYjyXIjEw3CmO/9XD9z4TDKvZs6Anl1RlZ0 bhMBdwLBXmaeJXERO/hxtyztsY/DBFywPwkGgyGs3YRr3HGIALyQ1ZB3dJMcNWsEx8FW jgiwJQVmtOC7spA2BOpPMzTZG9EAmSwA4R7wzPnT4kak1QcUzZgZy7Fu1MgxqmUkXnpT laT+lx3bflu3uUC+YSU99UbY8yaZCqxiyjnWmfsUOiVRsD73yYkEPUww81x3m/vjIWx6 0fzw==
X-Gm-Message-State: AIVw110aqaEsJa9ckxrXNKa+z809FtfZzDJUmkQwpa0xo2vwLG56BICZ xvD2Ta2Wbjxu8p1rv1x4FmQ+Vl3JdQ==
X-Received: by 10.37.218.71 with SMTP id n68mr11036282ybf.153.1500989491126; Tue, 25 Jul 2017 06:31:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.83.13.6 with HTTP; Tue, 25 Jul 2017 06:31:30 -0700 (PDT)
In-Reply-To: <CAEFuwkjAe1JA-hqLbnrXN=Q_fPYO=Q=7Pn=jRXGWQ0iC31EjEg@mail.gmail.com>
References: <a60975bbd3774d4cb4041ef0d005f642@XCH-ALN-001.cisco.com> <CAEFuwkgtYbvHQdRUJb3jmFgq3+dtfJ+ERdpgB8aeKXryVBYYTA@mail.gmail.com> <CAEFuwki9KYZuNgW6u7LYU4cAGY0XCgNZ_nY3xhkmxB_weM_0fA@mail.gmail.com> <ed8ccfc11e8a4951a2bf67d8ad34e16b@XCH-ALN-001.cisco.com> <CAEFuwkjAe1JA-hqLbnrXN=Q_fPYO=Q=7Pn=jRXGWQ0iC31EjEg@mail.gmail.com>
From: Pushpasis Sarkar <pushpasis.ietf@gmail.com>
Date: Tue, 25 Jul 2017 06:31:30 -0700
Message-ID: <CAEFuwkgCQudKkWytkvccBzYb3L6rN_QDf1RpTehEXqvCMx+UuQ@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "idr-ads@ietf.org" <idr-ads@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-idr-bgp-ls-node-admin-tag-extension.all@ietf.org" <draft-ietf-idr-bgp-ls-node-admin-tag-extension.all@ietf.org>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c07d10c6e277c0555245917"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/LP8UzIq16u6q0RS1bJ0MEwI4OGg>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 25 Jul 2017 13:31:35 -0000

Hi Les,

Thank you once again for helping me out with all the review comments.. I
have addressed all your comments and uploaded version 02. Please let me
know if you need any more issues to take care of.

Thanks and Regards,
-Pushpasis


On Thu, Jul 13, 2017 at 5:24 PM, Pushpasis Sarkar <pushpasis.ietf@gmail.com>;
wrote:

> Hi Les,
>
> Sorry once again for the late response. Please find comments inline...
>
>
> On Sat, Jul 8, 2017 at 1:42 PM, Les Ginsberg (ginsberg) <
> ginsberg@cisco.com>; wrote:
>
>> Pushpassis –
>>
>>
>>
>> Sorry for the delay in responding.
>>
>> You have not addressed all of the editorial comments I provided – please
>> do a second pass.
>>
> [Pushpasis] I did a second pass.. But I could not locate which one(s) I
> missed out. It will be great if you list them out for me. The htmlized diff
> you attached earlier does not exactly highlight the diffs.. :( Request your
> help here...
>
>
>>
>>
>> Also, there is one substantive issue which you did not address:
>>
>>
>>
>> *<snip>*
>>
>> *Section 3.1 Last paragraph*
>>
>>
>>
>> *I recognize this statement regarding policy being used to filter what is*
>>
>> *advertised is consistent with RFC 7752. But it would also be good to
>> include*
>>
>> *a statement like:*
>>
>>
>>
>> *"Definition of such a policy is outside the scope of this document."*
>>
>> *<end snip>*
>>
>>
>>
>> If you have a concern with what I proposed please let me know what it is.
>>
> [Pushpasis] I will be very happy to add the statement.  Thanks a lot for
> the suggestion.
>
> Thanks and Regards,
> -Pushpasis
>
>>
>>
>> Thanx.
>>
>>
>>
>>    Les
>>
>>
>>
>>
>>
>>
>>
>> *From:* Pushpasis Sarkar [mailto:pushpasis.ietf@gmail.com]
>> *Sent:* Tuesday, July 04, 2017 8:58 PM
>> *To:* Les Ginsberg (ginsberg)
>> *Cc:* idr-ads@ietf.org; rtg-dir@ietf.org; draft-ietf-idr-bgp-ls-node-adm
>> in-tag-extension.all@ietf.org; idr@ietf. org
>> *Subject:* Re: RtgDir review: draft-ietf-idr-bgp-ls-node-adm
>> in-tag-extension-01
>>
>>
>>
>> Hi Les,
>>
>>
>>
>> Thank you once more for the review comments. And sorry for the late
>> reply. I have addressed all your comments in the attached draft. Please
>> review the same let me know if you have any more comments. If not I will
>> upload the draft soon.
>>
>>
>>
>> Thanks and regards,
>>
>> -Pushpasis
>>
>>
>>
>> On Wed, Jun 28, 2017 at 10:26 PM, Pushpasis Sarkar <
>> pushpasis.ietf@gmail.com>; wrote:
>>
>> Hi Les,
>>
>>
>>
>> Thanks a lot for the review comments. I will reply back addressing your
>> comments soon.
>>
>>
>>
>> Thanks and regards
>>
>> -Pushpasis
>>
>>
>>
>> On Tue, Jun 27, 2017 at 11:37 PM, Les Ginsberg (ginsberg) <
>> ginsberg@cisco.com>; wrote:
>>
>> Hello,
>>
>>  I have been selected as the Routing Directorate reviewer for this draft.
>> The Routing Directorate seeks to review all routing or routing-related
>> drafts as they pass through IETF last call and IESG review, and sometimes
>> on special request. The purpose of the review is to provide assistance to
>> the Routing ADs. For more information about the Routing Directorate, please
>> see  http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir .
>>
>> Although these comments are primarily for the use of the Routing ADs, it
>> would be helpful if you could consider them along with any other IETF
>> comments that you receive, and strive to resolve them through discussion or
>> by updating the draft.
>>
>>
>> Document: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01
>> Reviewer: Les Ginsberg
>> Review Date: June 27, 2017
>> Intended Status: Standards
>>
>> Summary:  The document is of modest scope - covering definition of BGP-LS
>> codepoints for a relatively new IGP attribute (Node Admin Tags).
>> While I found nothing which I would consider a major issue, there are a
>> number
>> of places where the text lacks clarity. I think addressing these areas
>> would
>> greatly improve the quality of the draft.
>>
>>
>> Major Issues: None
>>
>> Minor Issues:
>>
>> Section 1 Introduction
>>
>> The acronym LSDB is not defined.
>>
>> Figure 1
>>
>> I have a personal dislike for duplicating text/pictures from another
>> spec when that spec could simply be referenced. There are only two
>> possible outcomes:
>>
>> 1)The duplicated text is redundant (best case)
>> 2)The text differs somewhat from the original leading to possible
>> unintentional misinterpretations.
>>
>> Suit yourself on this comment - but I would prefer the duplication be
>> omitted.
>>
>> Section 2 First paragraph
>>
>> You refer to "sub-TLV" but that reference is unclear and ambiguous.
>> IS-IS uses a sub-TLV of Router Capability to advertise tags, but OSPF
>> uses a TLV of Router Info LSA.
>> What seems most relevant here is that you are defining a new Attribute
>> TLV for Node NLRI.
>>
>> Section 3 Second paragraph
>>
>> I do not know what the paragraph is trying to say, nor do
>> I know what the "TBD" in columns 4 and 5 in the following Table 1 is
>> meant to reference. If you are simply trying to describe the source
>> of the info advertised by the new BGP-LS Node attribute then you should
>> rewrite the above paragraph and in the figure below show:
>>
>> IS-IS 242/21
>> OSPF RI-LSA/10
>>
>> Section 3.1
>>
>> A description of where in the Node NLRI the area/level information can be
>> found
>> (from RFC 7752) would be helpful.
>>
>>
>> Section 3.1 Penultimate Paragraph
>>
>> As TAGs with "global" scope will be advertised by the IGP multiple
>> times (once per area/level) I assume you are asking BGP-LS advertisements
>> to reduce these multiple occurrences to a single occurrence? More
>> explicit language on that point would be helpful.
>>
>> Section 3.1 Last paragraph
>>
>> I recognize this statement regarding policy being used to filter what is
>> advertised is consistent with RFC 7752. But it would also be good to
>> include
>> a statement like:
>>
>> "Definition of such a policy is outside the scope of this document."
>>
>> Nits: Please see attached diff file with some editorial corrections.
>>
>>
>>
>>
>>
>
>