Re: [Gen-art] Gen-ART Last Call review of draft-ietf-rtgwg-rlfa-node-protection-09

[Meral Shirazipour <[e-mail]>]

Hi,
  Many thanks for the response.

Best Regards,
Meral

From: Pushpasis Sarkar [mailto:[e-mail]]
Sent: Thursday, December 29, 2016 12:20 AM
To: Meral Shirazipour <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: Gen-ART Last Call review of draft-ietf-rtgwg-rlfa-node-protection-09

Hi Meral,

First, many many thanks to you for the detailed review comments. :)

Next, please find few replies inline. Rest of the comments has been accepted as is, and will be addressed soon.

Thanks
-Pushpasis


On Wed, Dec 28, 2016 at 11:03 PM, Meral Shirazipour <[e-mail]<mailto:[e-mail]>> wrote:
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-rtgwg-rlfa-node-protection-09
Reviewer: Meral Shirazipour
Review Date: 2016-12-28
IETF LC End Date:   2017-01-04 (extension 2017-01-11)
IESG Telechat date: 2017-01-05 (extended)


Summary:
This draft is ready to be published as Standards Track RFC but I have comments.

Major issues:
Minor issues:
Nits/editorial comments:

-Please spell out Loop-Free Alternate (LFA), Shortest Path First (SPF) at first use.

-typo in draft header:
"Internet-Draft   R-LFA Node-Protection and Manageabilty    December 2016"
                "Manageabilty"--should be-->"Manageability"

-Same typo in Section 3 header: "Manageabilty of Remote-LFA Alternate Paths"
                "Manageabilty"--should be-->"Manageability"

-[Page 6] Section 2.2.3.
"on any of the shortest path", path -->"paths"

-[Page 6] Section 2.2.3.
"from the node Y to primary nexthop E":
"one ECMP path from the node Y":
-->the example in this draft did not use the letter Y for any nodes. Would it be clearer to say node Y is defined in Section 2.2.4?

-Few occurences of "w.r.t to ", the "to" is redundant.

-[Page 1], "can be utilised "--->"can be utilized"

-[Page 9], Section 2.3
"Sections Section 2.3.1 and Section 2.3.2 shows "--->"Section 2.3.1 and Section 2.3.2 show"

-[Page 11], "To determine wether"--->"To determine whether"

-[Page 11], "primary nexthop node"-->"primary nexthop nodes"

-[Page 13], "choose only the ones that does"--->"choose only the ones that do"

-[Page 13], "not gaurantee"--->"not guarantee"

-[Page 14], "Figure 7: Toplogy with multiple ECMP primary nexthops"--->"Figure 7: Topology with multiple ECMP primary nexthops"

-[Page 14], "node-proecting"--->"node-protecting"

-[Page 15], "paths tp PQ-node R2"--->"paths to PQ-node R2"

-[Page 16], "gaurantees node-protection"--->"guarantees node-protection"

-[Page 17],  "above example above"--->"above example"

-[Page 17], "also allow user"--->"also allow the user"

-[Page 18], "the the computing"---->"the computing"

-[Page 18], "in section Section 2.3.2."---->"in Section 2.3.2." (2 occurrences)

-[Page 18], "in section Section 2.3 the"---->"in Section 2.3 the"

-[Page 18], "i.e from "---->"i.e. from "

-[Page 18], "two Remote-LFA alternate path"--->"two Remote-LFA alternate paths"

-[Page 19], "the approach proposed"----->"the proposed approach "

-[Page 19], "is needed keep "---->"is needed to keep"

-[Page 19], "entire toplogy"---->"entire topology"

-General: Is there any proof or extensive simulation that has proved that the mechanism proposed works for various network topologies and not only the one shown in the examples?

[Pushpasis] These mechanisms has been implemented (by atleast one vendor, to my knowledge) and has been extensively tested in few of the operator's network. As is the case with L-FA (RFC 5286) and R-LFA(RFC 7490) specifications, these mechanisms either provide you with a backup alternate, or does not. But if a backup is verified using these mechanism, it is 100% guaranteed to be loop-free. As you might be already be aware of, R-LFA is more suited towards ring-like network topologies. None of these mechanisms always provide 100% backup coverage (i.e. they do not always let you discover all the possible/feasible backup paths). But depending on actual topologies, they can provide coverage somewhere between 100%-86%. You may want to refer to RFC 7490 section 9. Please let me know if you need any further information on this.

Thanks
-Pushpasis



Best Regards,
Meral
---
Meral Shirazipour
Ericsson Research
www.ericsson.com<http://www.ericsson.com>