Re: [Last-Call] Genart last call review of draft-ietf-lsr-ospf-reverse-metric-07

Ketan Talaulikar <ketant.ietf@gmail.com> Wed, 21 September 2022 14:19 UTC

Return-Path: <ketant.ietf@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC95C14F735; Wed, 21 Sep 2022 07:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (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 J1CtRLGUBsrc; Wed, 21 Sep 2022 07:19:42 -0700 (PDT)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 BE06DC1522A9; Wed, 21 Sep 2022 07:19:23 -0700 (PDT)
Received: by mail-vs1-xe2d.google.com with SMTP id k2so6873739vsk.8; Wed, 21 Sep 2022 07:19:23 -0700 (PDT)
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; bh=d/lS9UlF93wZEovdKIiEgE656cU4fqVpgdvJY+YPUvI=; b=j3qHNnUCQ19NRrfWNyqhcXJSIm5QGfkvB8gJAmSfqvu5M+c9iULOROU6HnDumRmfyK vw8F+pBnfNxT6MGnv8X5OU7BFWcMpJMFa/G36zjYVf0bGHb4xzqtbTuWSRsIvs3YYISn wZP3Z684x1YGA+k1hsOhNo57pQfCGT/9crQZeyQYxtedACHHVOJ7Cd6C4wISywe/aVA3 0aMVMwcpQV6av14AsfX4J1WSNWOia4MvJeeglACZAqJmMGWVrSN8YZJs03sRh/XtHnbg JLNPoAMrLhWnmSnTwHYdjSalHfE7WtUzwvs0llpiXMoxav31y4Kc3c8dYx/CQh4w0WFN 1tmA==
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; bh=d/lS9UlF93wZEovdKIiEgE656cU4fqVpgdvJY+YPUvI=; b=RfVG8ZHFI6WPEYy5mQ7IMyC5GeJ9ukDqEuqwPkhimEl/wLeqfOsWMupRFsmjx/nAve QuQ2+pgJtUo2DJjMH8YoYZigcxR/apegJoCPAhR1Vy2/hX5N9shysu9NnGkztOAAiCJr KUQ8PmI9Kkn5oL4n+vZaEcC15DxySYGa/Wqrb4qsFTgiuA1qEoQ76JiYimb/D8D3RRdt SSM0aFDiEhaELOdIL5wYyUUnCtbV8GxJazZUoAgr2mPtKyU3HPlUncw4QWXqises1FU1 qW/uTFYRpu1sM3TcOIziIBkHu9ZiIwp1MwSJYla5xcijfv/dK5Hc+CUzJnob4aPJfTt1 yQrw==
X-Gm-Message-State: ACrzQf1yqTGj/M5SBaZp3Aaq+p0FLlSjXAP4vp9EUFk8/CNemq/eYphU tNwDz0GpGLbAPOQ29g1iemIc8gU4LTJkojLGfyY=
X-Google-Smtp-Source: AMsMyM7t+3oVNmTR4TQbfhzGJ1Z/m6BqUQqRU1b+fbgVrU4HcCGZMh+HCL2i0mk9z7UiF0DUmf2LJmPHL/W3sQaEAjE=
X-Received: by 2002:a67:c810:0:b0:39b:1ee0:fbfb with SMTP id u16-20020a67c810000000b0039b1ee0fbfbmr5019974vsk.34.1663769962689; Wed, 21 Sep 2022 07:19:22 -0700 (PDT)
MIME-Version: 1.0
References: <166272822888.47659.4683365954813452330@ietfa.amsl.com> <CAH6gdPzwraD5jFst9ba74c0eRucA-wVHhLbXJsd=539Z2RMdtg@mail.gmail.com> <DB9PR08MB652429DA376E527D95EA41549C479@DB9PR08MB6524.eurprd08.prod.outlook.com>
In-Reply-To: <DB9PR08MB652429DA376E527D95EA41549C479@DB9PR08MB6524.eurprd08.prod.outlook.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Wed, 21 Sep 2022 19:49:10 +0530
Message-ID: <CAH6gdPzfd7=FdUz3DivYi_NkzwL+W3QT88tLGtBAnRHpPc6TOw@mail.gmail.com>
To: Thomas Fossati <Thomas.Fossati@arm.com>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-lsr-ospf-reverse-metric.all@ietf.org" <draft-ietf-lsr-ospf-reverse-metric.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009d395805e930a163"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/TpO0YYIoZhRtE6QqWXhM7Ng28yo>
Subject: Re: [Last-Call] Genart last call review of draft-ietf-lsr-ospf-reverse-metric-07
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2022 14:19:46 -0000

Hi Thomas,

The updated version just posted includes the changes we discussed:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-08

Thanks,
Ketan


On Tue, Sep 13, 2022 at 8:16 PM Thomas Fossati <Thomas.Fossati@arm.com>
wrote:

> Thank you Ketan.
>
>
>
> On 13/09/2022, 07:52, "Ketan Talaulikar" <ketant.ietf@gmail.com> wrote:
>
>
>
> Hi Thomas,
>
>
>
> Thanks a lot for your detailed review and your suggestions. We've
> incorporated all of those changes and they will reflect in the next update
> of the document.
>
>
>
> Please check inline below for some responses.
>
>
>
>
>
> On Fri, Sep 9, 2022 at 6:27 PM Thomas Fossati via Datatracker <
> noreply@ietf.org> wrote:
>
> Reviewer: Thomas Fossati
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-lsr-ospf-reverse-metric-??
> Reviewer: Thomas Fossati
> Review Date: 2022-09-09
> IETF LC End Date: 2022-09-20
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
>
> This is a clear and easy to read document, thank you authors for the
> great job.
>
> I only have a couple of very minor issues / clarifications.  The tail of
> my review consists of a bunch of typographic nits and one suggestion for
> how to align the Contributors section to most recent interpretations of
> the RFC Style Guide (RFC7322).
>
>
>
> KT> Thanks for catching that. The goal was to actually acknowledge Jay. We
> will remove the contributors section and use the acknowledgement section
> instead.
>
>
>
>
> Major issues: none
>
> Minor issues:
>
> * It looks that the H and O flags are mutually exclusive?  If so, I
>   think the fact should be made explicit.  (This applies to both the
>   reverse and reverse TE metrics.)
>
>
>
> KT> Yes, they are de facto mutually exclusive - i.e., when the O flag is
> set, the offset is added to the existing metric and therefore guaranteed to
> be not lower than the existing metric. Therefore, when the O flag is set,
> the H flag can be ignored and we will add this explicitly in the text.
>
>
>
>
> * "If authentication is being used [...] then the Cryptographic
>   Authentication TLV [RFC5613] SHOULD also be used to protect the
>   contents of the LLS block."  Please explain why this is not a MUST,
>   i.e., under which conditions it is OK to not authenticate the LLS
>   block.
>
>
>
> KT> RFC5613 indeed covers this already and so it is a MUST ... "when
> authentication is used".
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
> Nits/editorial comments:
>
> Section 1., paragraph 1:
> OLD:
>     Thus the configuration on R1 influences the traffic that it forwards
>
> NEW:
>     Thus, the configuration on R1 influences the traffic that it
>     forwards
>
>
> Section 2.1., paragraph 2:
> OLD:
>     when a large number of CE routers connect to a PE router, an
>
> NEW:
>     when many CE routers connect to a PE router, an
>
>
> Section 2.1., paragraph 3:
> OLD:
>     router to advertise the maximum metric for that link and also to
>     [...]
>     returns to using its provisioned metric for the link and also stops
>
> NEW:
>     router to advertise the maximum metric for that link and to
>     [...]
>     returns to using its provisioned metric for the link and stops
>
>
> Section 2.2., paragraph 2:
> OLD:
>     reverse metric to some or all of the R1-RN routers.  When the R1-RN
>
> NEW:
>     reverse metric to some or all the R1-RN routers.  When the R1-RN
>
>
> Section 3., paragraph 1:
> OLD:
>     This ensures that the RM signaling is scoped ONLY to each specific
>     [...]
>     Metric TLV in its Hello packets on the link as long as it needs its
>     [...]
>
> NEW:
>     This ensures that the RM signaling is scoped only to each specific
>     [...]
>     Metric TLV in its Hello packets on the link for as long as it needs
>     its [...]
>
>
> Section 6., paragraph 4:
> OLD:
>     instability in the network due to churn in their metric due to
>     signaling of RM:
>
> NEW:
>     instability in the network due to churn in their metric caused by
>     signaling of RM:
>
>
> Section 6., paragraph 7:
> OLD:
>     RM metric signaling based on the RM metric signaling initiated by
>     some other router.
>
> NEW:
>     RM metric signaling based on the RM metric signaling initiated by
>     some other routers.
>
>
> Section 6., paragraph 10:
> OLD:
>     (also refer to Section 7 for details on enablement of RM).  The
>     rules [...]
>
> NEW:
>     (refer to Section 7 for details on enablement of RM).  The rules
>     [...]
>
> Section 7., paragraph 5:
> OLD:
>     For the use case in Section 2.1, it is RECOMMENDED that the network
>     operator limit the period of enablement of the reverse metric
>
> NEW:
>     For the use case in Section 2.1, it is RECOMMENDED that the network
>     operator limits the period of enablement of the reverse metric
>
>
> Section 9., paragraph 1:
> OLD:
>     This document allocates code points from Link Local Signalling TLV
>     Identifiers registry for the TLVs introduced by it as below.
>
> NEW:
>     This document allocates code points from the Link Local Signalling
>     TLV Identifiers registry for the introduced TLVs.
>
>
> Regarding the Contributors section, I think BCP is to make it similar to
> the Authors section, e.g.:
>
> Section 11., paragraph 1:
> OLD:
>     Thanks to Jay Karthik for his contributions to the use cases and the
>     review of the solution.
>
> NEW:
>     Jay Karthik
>     Cisco Systems, Inc.
>     Email: jakarthi@cisco.com
>
>     Jay contributed to the use cases and the review of the solution.
>
>
> If you are using kramdown-rfc you can add this snippet after your
> "author" block
>
> contributor:
>  -  name: Jay Karthik
>     email: jakarthi@cisco.com
>     contribution: Jay contributed to the use cases and the review of the
> solution.
>
> Otherwise (xml2rfc):
>
>   <contact initials="J." surname="Karthik" fullname="Jay Karthik">
>     <organization>Cisco Systems, Inc.</organization>
>     <address>
>       <email>jakarthi@cisco.com</email>
>     </address>
>   </contact>
>   <t>
>     Jay contributed to the use cases and the review of the solution.
>   </t>
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>