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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
