Hi Benoit, Sure. I will add this clarification too in the next version.
Thanks -Pushpasis On Fri, Jan 20, 2017 at 2:10 PM, Benoit Claise <[email protected]> wrote: > On 1/19/2017 12:05 PM, Pushpasis Sarkar wrote: > > Hi Benoit, > > Many many thanks for your review comments. Please find answers inline... > > On Thu, Jan 19, 2017 at 3:27 PM, Benoit Claise <[email protected]> wrote: > >> Benoit Claise has entered the following ballot position for >> draft-ietf-rtgwg-rlfa-node-protection-10: Discuss >> >> 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 >> 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/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This document mentions manageability in his title. Hence my special >> focus. >> I'm with Eric Vyncke here. His OPS DIR review is: >> >> Not being an expert in LFA, the review focus was only on operation. >> And, due to the density and specialization of the I-D, I would like to >> ask the authors whether they read RFC 5706 about 'ops and mgmt >> guidelines', i.e., to check whether this I-D considered migration from an >> existing LFA to the new one, interoperations with previous LFA and how >> correct operations can be verified. >> As the core topic is about loop-free alternates, we can assume that fault >> management and operations are at the core of this I-D. But, I encourage >> the authors to quickly review their document with RFC 5706 in mind. >> >> After reading the document (and with basic knowledge of RLFA), I'm unable >> to tell at this point if RFC 7916 is still valid for this new >> functionality, if it needs to be updated, or even if >> https://tools.ietf.org/html/draft-ietf-rtgwg-rlfa-node-prote >> ction-10#section-3 >> is complete in light of RFC 5706. I'll be watching the discussion with >> interest. >> >> [Pushpasis] > I have provided an elaborate explanation in reply to OPS DIR review > comments from Eric. Request you to please refer to that.. :) And please let > us know if we are missing anything specific here.. > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> - The resulting Remote-LFA >> alternate nexthops (also referred to as the PQ-nodes) may not >> provide >> node-protection for all destinations covered by the same, in case of >> failure of the primary nexthop node. >> >> Covered by the same? >> > my point is: aren't you missing a word after "by the same"? > > Regards, B. > > [Pushpasis] The reference here is to the PQ-node computed using RFC7490 > specification which only gaurantees protection against failure of first-hop > link and not against failure of first-hop node(or router).. > I will try to change the text to clarify this.. > >> >> - There are also some nits and typos such as " uitilized" in the >> abstract. >> > [Pushpasis] I will take care of this in a next version shortly. > > Thanks once again and Regards, > -Pushpasis > > >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
