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