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

[Pushpasis Sarkar <[e-mail]>]

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]> 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
>