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

[Mirja Kühlewind <[e-mail]>]

Sorry, it was 'this document proposes' (not recommends)... yes better to use 
'specifies' instead!

On 18.01.2017 03:51, Pushpasis Sarkar wrote:
> Hi Mirja,
>
>     - 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?
>
> Actually, I don't see the term 'recommends' anywhere in the current version.
> So now I am not sure what was the comment about :( Request you to clarify
> this a bit, so that I can take the right resolution..
>
> Thanks and regards,
> -Pushpasis
>
> On Wed, Jan 18, 2017 at 8:12 AM, Pushpasis Sarkar <[e-mail]
> <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>> 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.
>
>         - 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
>
>         - 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.
>
>     Thanks once again
>     -Pushpasis
>
>