Telechat Review of draft-ietf-rtgwg-mrt-frr-algorithm-08

Request Review of draft-ietf-rtgwg-mrt-frr-algorithm
Requested rev. no specific revision (document currently at 09)
Type Telechat Review
Team Ops Directorate (opsdir)
Deadline 2016-02-02
Requested 2016-02-04
Authors Gabor Envedi, Andras Csaszar, Alia Atlas, Chris Bowers, Abishek Gopalan
Draft last updated 2016-02-13
Completed reviews Secdir Last Call review of -08 by Russ Housley (diff)
Opsdir Telechat review of -08 by Nevil Brownlee (diff)
Assignment Reviewer Nevil Brownlee 
State Completed
Review review-ietf-rtgwg-mrt-frr-algorithm-08-opsdir-telechat-brownlee-2016-02-13
Reviewed rev. 08 (document currently at 09)
Review result Ready
Review completed: 2016-02-13


Hi all:

I have performed an Operations Directorate review of

  "A solution for IP and LDP Fast-Reroute using Maximally Redundant
   Trees is presented in draft-ietf-rtgwg-mrt-frr-architecture.  This
   document defines the associated MRT Lowpoint algorithm that is used
   in the Default MRT profile to compute both the necessary Maximally
   Redundant Trees with their associated next-hops and the alternates to
   select for MRT-FRR."

This draft is a companion to the nrt-frr-achitecture, providing (and
explaining) the algorithms needed for the architecture.  The algorithms
come from a PhD thesis; I assume they are correct - though I have not
read the thesis.

I found the term "ear" hard to get used to.  An ear is, I think, an
alternative path added to an ADAG (Almost DAG), providing alternative
paths through that ADAG but gauranteeing that no loops are introduced
to the ADAG.  My problem with "ear" is that it doesn't seem to have
any mneumonic power, i.e. EAR doesn't seem to be an acronym.

The component parts of the algorithm (sub-algorithms) are described
using small graphs, explanatory text and a pseudo-language that looks
rather like python.  The sub-algorithms include tables that span
several pages.  Appendix A gives a complete python implementation,
which should be useful to anyone considering a new implementation -
anyone doing that will need to read the whole draft carefully, and be
sure that they understand the algorithms completely _before_ that
start writing code!

Section 10, Operational Considerations, contains some useful comments
that point out aspects of these algorithms that Operators should
consider.  Overall though, Operators are encouraged to do some off-line
analysis to satisfy themselves that the system works effectively

The draft is well-written and presents the algorithms clearly.
In my opinion it's ready for publication as an RFC.

Cheers, Nevil

 Nevil Brownlee                          Computer Science Department
 Phone: +64 9 373 7599 x88941             The University of Auckland
 FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand