Subject: Re: shephard comments on draft-ietf-rtgwg-rlfa-node-protection-05

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 15 Nov 2016 10:50:28 +0530

[+rtgwg]

Looks like I forgot to add the WG mailing list while replying to Jon's
comment earlier.

Thanks and regards,
-Pushpasis

On Mon, Nov 7, 2016 at 4:45 PM, Pushpasis Sarkar <[email-masked]>
wrote:

> Hi Jon
>
> Once again thanks a lot for the comments. Please find some comments and
> resolutions inline below.
>
> Thanks and Regards,
> -Pushpasis
>
>
> On Sun, Nov 6, 2016 at 11:30 AM, Jon Mitchell <[email-masked]>
> wrote:
>
>>
>> Re-forwarding this message now that Pushpassis is asking for WGLC.  Can
>> you please address these comments authors?
>>
>> On 31/05/16 21:28 -0400, Jon Mitchell wrote:
>> >
>> > Authors -
>> >
>> > Hello, I'm the doc shephard for draft-ietf-rtgwg-rlfa-node-protection
>> > and as I was filling out the shephard report, had the following three
>> > issues I think might be easily agreeable to fix before submitting the
>> > write-up if you agree:
>> >
>> > 1.  The abstract should standalone as a description of the document, but
>> > I feel the current one goes deep fairly quickly, and may not be
>> > sufficient for the average IP / routing oriented reader to understand
>> > the document context sufficiently.  Could a few sentences be added so
>> > that it's clear that this document is about IP FRR and Loop Free
>> > Alternates (even this is abbreviated currently)?  This may not be the
>> > best text but even just one more first sentence if phrased correctly may
>> > lead some clarity to the abstract:
>> >
>> > This document describes an extension to the basic IP fast reroute
>> > mechanism, described in RFC 5286, that ..., in contrast to RFC 7490 that
>> > ...
>>
> [Pushpasis] To my thinking this document is more of an extension to RFC
> 7490 which is an extension to RFC 5286.. I have reworded the Abstract based
> on this and your comment . Let me know this looks good enough or not.
>
> "
>
> Abstract
>
>    The loop-free alternates computed following the current Remote-LFA
>    specification guarantees only link-protection.  The resulting Remote-
>    LFA nexthops (also called PQ-nodes), may not guarantee node-
>    protection for all destinations being protected by it.
>
>    This document describes an extension to the Remote Loop-Free based IP
>    fast reroute mechanisms described in [RFC7490], that describes
>    procedures for determining if a given PQ-node provides node-
>    protection for a specific destination or not.  The document also
>    shows how the same procedure can be utilised for collection of
>    complete characteristics for alternate paths.  Knowledge about the
>    characteristics of all alternate path is precursory to apply operator
>    defined policy for eliminating paths not fitting constraints.
>
> "
>
>
>> >
>> > 2.  I believe two of the references, those to RFC 5286 / RFC 7490 are
>> > normative given that parts of the document reference them for how to
>> > understand the content of this document, especially in section 2.2.
>> > Note also that RFC 7490 has RFC 5286 as normative.
>> >
>>
> [Pushpasis] Done. I will move these two to the normative reference section.
>
>
>> > 3.  Please search for RFC 2119 improper usage (lower case MUST NOT,
>> > SHOULD NOT).  There are also questionable uses of MAY that I feel are
>> > RFC 2119 covered but are not covered by the nits tool.
>> >
>>
>
> [Pushpasis] I have reworded few sections to avoid ambiguity, as well as
> add specific details wherever it is absolutely meant to.. Please find a
> draft copy attached and let me know if you see any more discrepancies.
>
>
>> > There were also some nits below I don't plan on including in the
>> > write-up regardless but may save the RFC Editor some cycles.
>> >
>> > -Jon
>> >
>> > Introduction -
>> >
>> > 2nd paragraph, 1st sentence: 2nd comma should be
>> > striked, also s/run a/run an/
>> >
>>
> [Pushpasis] Done. Here is how it is after correction..
> "
>
>    Also, the LFA Manageability [RFC7916] document requires a computing
>    router to find all possible (including all possible Remote-LFA)
>    alternate nexthops, collect the complete set of path characteristics
>    for each alternate path, run an alternate-selection policy
>    (configured by the operator) and find the best alternate path.
>
> "
>
> > 3rd paragraph - 1st sentence: s/is run on/is run with/
>> >
>>
> [Pushpasis] Done. Here it is after correction.
>
> "
>
>    With current LFA [RFC5286] and Remote-LFA implementations, the
>    forward SPF (and reverse SPF) is run with the computing router and
>    its immediate 1-hop routers as the roots.
>
> "
>
> > Section 2 -
>> >
>> > 1st paragraph, 2nd sentence: perhaps a more exact statement than
>> > "significant additional performance complexities" could be used as
>> > performance is typically associated with forwarding NDR.  Is this meant
>> > to say that non-stop-routing has "complex state synchronization between
>> > redundant control plane hardware" or something else regarding difficult
>> > of vendor support or probability of software bugs?
>> >
>>
> [Pushpasis] Software bugs are implementation-specific problems.. But
> overall all NSR designs bring in some sort of synchronization between
> redundant control plane hardwares, as you have rightly pointed out.. But
> that by itself would not have been a issue, if the same is not associated
> with additional significant CPU and other resource consumptions.. I have
> modified the text a bit to include both.. Here is how it looks now..
>
> "
>
>    Certain operators refrain from deploying non-stop-routing in their
>    network, due to the required complex state synchronization between
>    redundant control plane hardwares it requires, and the significant
>    additional performance complexities it hence introduces.
>
> "
>
>> > Section 2.3.1 -
>> >
>> > 2nd paragraph, 1st sentence: s/direct neighbor/direct neighbors.  Last
>> > sentence lacks terminating punctuation.
>>
> [Pushpasis] Corrected
>
>
>> >
>> > 3rd paragrah, 1st sentence: extra space after "Table 3"
>> >
>>
> [Pushpasis] Corrected
>
> > Section 2.3.2 -
>> >
>> > 2nd paragraph, last sentence: ensure this/that twice, maybe strike first
>> > one.
>> >
>>
> [Pushpasis] I have reworded the last sentence a bit. Here is the full
> paragraph after modifying.. Let me know if this looks fine to you..
>
> "
>
>    To find a node-protecting R-LFA path for a given destination, the
>    computing router needs to pick a subset of PQ-nodes from the
>    candidate node-protecting PQ-space for the corresponding primary
>    nexthop, such that all the path(s) from the PQ-node(s) to the given
>    destination remain unaffected in the event of a node failure of the
>    primary nexthop node.  To determine wether a given PQ-node belongs to
>    such a subset of PQ-nodes, the computing router MUST ensure that none
>    of the primary nexthop node are found on any of the shortest paths
>    from the PQ-node to the given destination.
>
> "
>
>
>
>> > 3rd paragraph - Consider striking 2nd sentence lead in with much
>> > shorter: This will determine if a given ....
>> >
>>
> [Pushpasis] Done.
>
>
>> > Section 2.3.3
>> >
>> > 1st paragraph, 1st sentence - not clear if first two commas add clarity
>> > to first fragment or confusion, try striking both and the word "one".
>> >
>>
> [Pushpasis] I have a reworded a bit like below. Let me know if this looks
> fine..
>
> "
>
>    In addition to the extra reverse SPF computations suggested by the
>    Remote-LFA [RFC7490] draft (one reverse SPF for each of the directly
>    connected neighbors), this document proposes a forward SPF
>    computations for each PQ-node discovered in the network.
>
> "
>
>> > Section 3.2 -
>> >
>> > 2nd paragraph, 1st sentence - trouble groking "Like specified" in this
>> > sentence, is this the same as the word "As"
>>
> [Pushpasis] Replaced "Like specified" --> "As already specified"
>
>
>> >
>> > Authors' Addresses -
>> >
>> > I don't think it's proper/accepted to publish two email addresses for
>> > the same author.  A single long lived email should be utilized.
>>
> [Pushpasis] Yup. Replaced with a long-living email-id (hopefully) :)
>
> Thanks once again
> Pushpasis
>
> >
>>
>
>

---

From: Jon Mitchell <[email-masked]>
Date: Wed, 16 Nov 2016 20:16:46 -0500

> Looks like I forgot to add the WG mailing list while replying to Jon's

Pushpasis -

The changes you plan to publish in revision -08 look good to me, nit,
you have introduced a double comma in Section 2.2.5 paragraph 2.

Jon

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 17 Nov 2016 09:54:28 +0530

Hi Jon

Thanks a lot for the review comments.
I will take care of the nits and upload the draft.

Best regards
Pushpasis

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 16 Nov 2016 22:34:32 -0800

Hi Jon,

Thank you for the great job shepherding the draft.

Please upload the shepherd review so we could proceed with the draft.

Thanks!

Cheers,

Jeff

From: Pushpasis Sarkar <[email-masked]>
Date: Wednesday, November 16, 2016 at 20:24
To: Jon Mitchell <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, RTGWG <[email-masked]>
Subject: Re: shephard comments on draft-ietf-rtgwg-rlfa-node-protection-05
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, Chris Bowers <[email-masked]>
Resent-Date: Wed, 16 Nov 2016 20:24:43 -0800 (PST)

Hi Jon

Best regards
Pushpasis