Re: Mirja Kühlewind's No Objection on draft-ietf-rtgwg-rlfa-node-protection-10: (with COMMENT)

Mirja Kühlewind <ietf@kuehlewind.net> Wed, 18 January 2017 15:39 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269FD129476 for <rtgwg@ietfa.amsl.com>; Wed, 18 Jan 2017 07:39:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.101
X-Spam-Level:
X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 ACYHRc3e9K61 for <rtgwg@ietfa.amsl.com>; Wed, 18 Jan 2017 07:39:13 -0800 (PST)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21C89129461 for <rtgwg@ietf.org>; Wed, 18 Jan 2017 07:39:09 -0800 (PST)
Received: (qmail 11507 invoked from network); 18 Jan 2017 16:32:27 +0100
Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 18 Jan 2017 16:32:27 +0100
Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-rtgwg-rlfa-node-protection-10: (with COMMENT)
To: Pushpasis Sarkar <pushpasis.ietf@gmail.com>
References: <148458441463.22600.5019628198022110802.idtracker@ietfa.amsl.com> <CAEFuwkit6gUtMuV90vFaFHe4NwK+1bsSCv3EEmhjKYStF7M0Ew@mail.gmail.com>
From: Mirja Kühlewind <ietf@kuehlewind.net>
Message-ID: <ac46526b-2e3b-0e95-aee6-db158d5ea00b@kuehlewind.net>
Date: Wed, 18 Jan 2017 16:32:26 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CAEFuwkit6gUtMuV90vFaFHe4NwK+1bsSCv3EEmhjKYStF7M0Ew@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/GpDHra9F8IiysTrRGANvEw-ZedE>
Cc: draft-ietf-rtgwg-rlfa-node-protection@ietf.org, rtgwg-chairs <rtgwg-chairs@ietf.org>, The IESG <iesg@ietf.org>, RTGWG <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jan 2017 15:39:14 -0000

Hi Pushpasis,

thank for your replies. Please see below!

Mirja

On 18.01.2017 03:42, Pushpasis Sarkar wrote:
> Hi Mirja,
>
> Thanks a lot for the comments. And sorry for not being able to reply earlier.
> Please find some comments  inline.
>
> Thanks
> -Pushpasis
>
> On Mon, Jan 16, 2017 at 10:03 PM, Mirja Kuehlewind <ietf@kuehlewind.net
> <mailto:ietf@kuehlewind.net>> wrote:
>
>     Mirja Kühlewind has entered the following ballot position for
>     draft-ietf-rtgwg-rlfa-node-protection-10: No Objection
>
>     When responding, please keep the subject line intact and reply to all
>     email addresses included in the To and CC lines. (Feel free to cut this
>     introductory paragraph, however.)
>
>
>     Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>     <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>     for more information about IESG DISCUSS and COMMENT positions.
>
>
>     The document, along with other ballot positions, can be found here:
>     https://datatracker.ietf.org/doc/draft-ietf-rtgwg-rlfa-node-protection/
>     <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-rlfa-node-protection/>
>
>
>
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>
>     Overall comment: This reads rather like an informational rfc; however
>     given that rfc7490 is standards track, I guess that's fine.
>
>     More specific comments:
>     - More abbreviations could be spelled out to make it easier to read.
>
> [Pushpasis] I will try to add as many as I can in the next version :)
>
>     - Not sure what section 3 tells me; but I'm also not an expert.
>
> [Pushpasis] Section 3 is about a using the same solution proposed to find a
> node-protected R-LFA path by running a forward-SPF on the PQ node(s) to
> select parameters of the same paths discovered, so that the computing router
> on discovering multiple R-LFA backup paths to a single destination can run
> some backup-path-selection policies on the same path parameters collected
> (while doing computing F-SPF) to select one or more best suited R-LFA backup
> paths for the destination. Hope it explains :) You may also want to refer to
> RFC7916 for more explanation.

Still not clear to me. Anyway I'm not an expert and maybe I'm missing 
something. Or let me ask the questions differently: What does this part add 
to the rest of the doc and why is this a separate section?

>
>     - Also section 3: "As already specified in Section 2.3.4 to limit the
>     computational
>        overhead of the proposed approach, forward SPF computations MUST be
>        run on a selected subset from the entire set of PQ-nodes computed in
>        the network, with a finite limit on the number of PQ-nodes in the
>        subset."
>        I guess you don't need the upper case MUST here.
>
> [Pushpasis] Actually this was suggested to be exactly a MUST in WG
> discussions on the WG mail

My point was, given this is a MUST in section 2.3.4 and this sentence starts 
with "As already specified in Section 2.3.4" it does have to be an upper case 
MUST here again (because it's correctly normatively specified in section 
2.3.4). However not a big issue.

>
>     - Also then in section 2.3.4: "To limit the computational overhead of the
>     approach proposed, this
>        document proposes that implementations MUST choose a subset from the
>        entire set of PQ-nodes computed in the network, with a finite limit
>        on the number of PQ-nodes in the subset."
>        Saying "this doc recommends" and "MUST" in the same sentence seem
>     inaccurate.
>
> [Pushpasis] Should I replace 'recommends' with 'specifies' then?
>
>     - And also section 2.3.4: Could you maybe suggest or discuss an
>     appropriate default value?
>
> [Pushpasis] I have myself implemented it for Juniper and the default value as
> 16. I can specify the same as a suggested default. But I am not sure it will
> be raise any concern in the WG or not. If you suggest, I can go ahead and put
> this in the next version.

If you think this could raise any concerns in the wg, you should go back to 
the wg mailing list and ask for feedback/confirmation.



>
> Thanks once again
> -Pushpasis
>