Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-summary-frr-rsvpte.txt

"Andrew G. Malis" <agmalis@gmail.com> Wed, 13 November 2019 12:56 UTC

Return-Path: <agmalis@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 1B6651208C2; Wed, 13 Nov 2019 04:56:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 f9dGgQEzHxc5; Wed, 13 Nov 2019 04:56:32 -0800 (PST)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 EB0AB1208C1; Wed, 13 Nov 2019 04:56:31 -0800 (PST)
Received: by mail-qt1-x830.google.com with SMTP id t8so2433368qtc.6; Wed, 13 Nov 2019 04:56:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J3ONao3hH6mg/WF6PXyWPVMPhF7ZasJw78PGkcRP6ew=; b=iridoBTjPHjR4QM/DH3IF1Wt6AiktsMQJYo53Wkj758SpHdrF4jTUXExzb/VBjcaoW i9RMbKX1Aj+q1GY7HFhmURP6CaGJDAV8zgFDuWujcj6AVd3j2XYQzrLt0nObhrBJs1J7 1ns2u59vIgcpiVUTC1yeOcd6ZVDuqlAx0Bk8RqCr3WM25QkszhC39JRR67v4g1H8J3kq EnadzlHZM94z2paV3Vh1Q4wP807OquwCV3aT9m4cKzxjTKeIVQ6o7fU+5jAupHbqQuYR 4IFguZFqmR9GbHg2zC5oExhVHXsU05tvE6mwOSZT9XFi+PsjVtvXlTPcyYUTfAJ5cQZo 7Akw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J3ONao3hH6mg/WF6PXyWPVMPhF7ZasJw78PGkcRP6ew=; b=ZgQd5sw9n2iLfUyGqvU/2ez34f49dzlCU7Fiep1TF21l8Cv2Ti44lgr0pFfB9f985w 3pY/At9pYsODvl8u2fcPsJdlJz67q8bs4SBlzSKnIBby78GyiXgNDTFR/FyK2y5G4I6s 9orEVbRUgi4O9EI8LzMA9hLLCfnNBbbHrx8T9Ga5nsfaawOSDWZ0MV+cUS6nR8bhK1/H 3O1Mkg0ltf2DK2y7A1scZwVf25bRrUrcqiUr1Y+WVXMQXa62m7IvJUnOCnHSNQ72i2F5 L+OVPizSHn8sQEk5j5i+WU9t2+4fnjAyQTUZ94G6bvGaZ41GtzlkMTzL7onOVJ37PmQe ugsw==
X-Gm-Message-State: APjAAAUZKJjiWKL/tF2A8lqz1hfO4dRoa0hAkhoCmf6H6xSOP+KsNjS9 OmDed3pC+4s1G2hXaFchiUHBGnppYf/1D5c35D4JQamYCh0=
X-Google-Smtp-Source: APXvYqzt9zR65C8L+ccEdLa09arKHWO4gOmyEJ4gEg5mwMABsQKcSsT2bx7OQCCATa7CPHWpTGkTkzq/lfMepTuZirA=
X-Received: by 2002:aed:36a1:: with SMTP id f30mr2354693qtb.154.1573649790890; Wed, 13 Nov 2019 04:56:30 -0800 (PST)
MIME-Version: 1.0
References: <CAA=duU1QP-Jk4gSAqvsH7YrTuiAuW6r369QNPxrchH9nNBLK6Q@mail.gmail.com> <DM6PR19MB3689D3A86109608B0CBBAE01FC770@DM6PR19MB3689.namprd19.prod.outlook.com>
In-Reply-To: <DM6PR19MB3689D3A86109608B0CBBAE01FC770@DM6PR19MB3689.namprd19.prod.outlook.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Wed, 13 Nov 2019 07:56:20 -0500
Message-ID: <CAA=duU0JVxCdzozjPJjwBJw=a66HYdfH9ofW2X8kxO+3FFEXkA@mail.gmail.com>
To: Tarek Saad <tsaad.net@gmail.com>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-mpls-summary-frr-rsvpte.all@ietf.org" <draft-ietf-mpls-summary-frr-rsvpte.all@ietf.org>, mpls <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c975cb059739e4db"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/qY_N_StI1kHGB_7SI2YTDEUyA0U>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-summary-frr-rsvpte.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 13 Nov 2019 12:56:35 -0000

Tarek,

You're very welcome!

One more small thing I noticed, seeing as you haven't uploaded yet .... :-)

The second paragraph in section 3 starts "This document proposes". It's no
longer a proposal, it should be "This document defines".

Cheers,
Andy


On Tue, Nov 12, 2019 at 10:31 AM Tarek Saad <tsaad.net@gmail.com> wrote:

> Hi Andy,
>
>
>
> Thanks much for you thorough review and comments. I’ve updated the draft
> to address those (attached is the diff from latest version). I’ll wait for
> the I-D submission tool to reopen and upload it. Inline for further
> response.
>
>
>
>
>
>
>
>
> *From: *"Andrew G. Malis" <agmalis@gmail.com>
> *Date: *Monday, November 4, 2019 at 3:14 PM
> *To: *"<rtg-ads@ietf.org>" <rtg-ads@ietf.org>
> *Cc: *"rtg-dir@ietf.org" <rtg-dir@ietf.org>, "
> draft-ietf-mpls-summary-frr-rsvpte.all@ietf.org" <
> draft-ietf-mpls-summary-frr-rsvpte.all@ietf.org>, mpls <mpls@ietf.org>
> *Subject: *RtgDir review: draft-ietf-mpls-summary-frr-rsvpte.txt
> *Resent-From: *<alias-bounces@ietf.org>
> *Resent-To: *<mtaillon@cisco.com>, Tarek Saad <tsaad@juniper.net>, Rakesh
> Gandhi <rgandhi@cisco.com>, <adeshmukh@juniper.net>, <
> mjork@128technology.com>, <vbeeram@juniper.net>, <mach.chen@huawei.com>, <
> tsaad.net@gmail.com>, <n.leymann@telekom.de>, <loa@pi.nu>, <
> martin.vigoureux@nokia.com>, <db3546@att.com>, <aretana.ietf@gmail.com>,
> Nicolai Leymann <n.leymann@telekom.de>
> *Resent-Date: *Monday, November 4, 2019 at 3:14 PM
>
>
>
> 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
> <https://urldefense.com/v3/__http:/trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir__;!8WoA6RjC81c!Xd-eP3UaAlzqvmEhzY7YofdmKwqzGOjHTZKNtY_tb41RRprKAQL_INl9G5AWmQ$>
>
> 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 Last
> Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
>
> Document: draft-ietf-mpls-summary-frr-rsvpte.txt
> Reviewer: Andy Malis
> Review Date: 4 November 2019
> IETF LC End Date: N/A (not yet last-called)
> Intended Status: Standards Track
>
> Summary:
>
> This document is basically ready for publication, but has nits that should
> be considered prior to publication.
>
> Comments:
>
> This is a well-written draft that is easy to follow. The draft has
> benefitted from previous reviews, including during WG Last Call, when an
> issue arose regarding the MTU size of the bypass tunnel resulting from FRR.
> The draft is an extension to existing RSVP-TE signaling to reduce the
> amount of signaling and increase the scalability for FRR. The draft is
> careful to be backwards compatible with nodes that do not support it.
>
> Major Issues:
>
> No major issues found.
>
> Minor Issues:
>
> No minor issues found.
>
> Nits:
>
> Section 1, second paragraph: "large scale RSVP-TE LSPs deployment" ->
> "large scale RSVP-TE deployment"
>
> [TS]: addressed as proposed.
>
>
> Section 2.1: The key words paragraph is out of date. The current wording
> is:
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
> "OPTIONAL" in this document are to be interpreted as described in
> BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
> capitals, as shown here.
>
> RFC 8174 should also be added as a normative reference.
>
> [TS]: thanks, this has been updated now.
>
>
> Section 3.1.2:
>
> "The PLR MUST generate a new Message_Identifier each time the contents
>  of the B-SFRR-Ready Extended ASSOCIATION ID changes; for example,
>  when PLR node changes the bypass tunnel assignment." ->
> "The PLR MUST generate a new Message_Identifier each time the contents
>  of the B-SFRR-Ready Extended ASSOCIATION ID changes (e.g,,
>  when the PLR node changes the bypass tunnel assignment)."
>
> [TS]: addressed as proposed.
>
>
> Section 4: The title of this section may be better as "Backwards
> Compatibility" rather than just "Compatibility".
>
> [TS]: addressed as proposed.
>
>
>
>
> Section 5: "message, a slightly" -> "message, slightly"
>
> [TS]: addressed as proposed.
>
>
> Section 6: This section includes the URL for an IANA registry. These may
> change over time as IANA reorganizes their registries, and thus just
> referencing the appropriate registry and sub-registry by name is sufficient.
>
> [TS]: removed url and kept the reference by name.
>
>
> This section also contains a reference to the IANA "Resource Reservation
> Protocol (RSVP) Parameters" registry, but that registry isn't referenced
> elsewhere in the text and should be removed from this section.
>
> [TS]: removed as not needed.
>
>
>
> Regards,
>
> Tarek
>
>
>
> Regards,
> Andy
>
>
>
>
>