Hi all:

I have performed an Operations Directorate review of
   draft-ietf-rtgwg-mrt-frr-architecture-09

  "This document defines the architecture for IP/LDP Fast-Reroute using
   Maximally Redundant Trees (MRT-FRR).  MRT-FRR is a technology that
   gives link-protection and node-protection with 100% coverage in any
   network topology that is still connected after the failure."

This is a long draft, presenting the MRT-FRR architecture, and exploring
in some detail the design alternatives that were possible during that
process.

There are many acronyms used throughout the draft, that will work well
for routers familiar with Routing in general, and MPLS in particular.
Others will find it useful to keep a browser window at hand!  For me,
PLR (Point of Local Repair) was new.

In section 11.1, the equations that test whether a path is loop-free
for nodes S and F use D_opt() as an abbreviation for Distance_opt()
[RFC 5286] - I understand the authors wish to get these equations onto
single lines, but the phrase "where D_opt() means Distance_opt()" would
be helpful.

Throughout the draft the phrase "protocol extensions to .. will be
defined elsewhere" appears, similarly the IANA Considerations section
defines an MPLS Multi-Topology Identifiers Registry, but says that
codepoints in it will be defined elsewhere.  Clearly this draft is
the first in what will become a cluster of RFCs.

On the Operations side of things, section 1.2 notes that "MRT-FRR
supports partial deployment."  That will allow Operators to deploy
it in stages (one MRT Island at a time?).

Further, several sections consider the possibility of "link-protecting
alternates causing route looping," it seems that MRT-FRR should remain
loop-free.

Section 13, Implementation Status [to be removed by the RFC Editor],
demonstrates that at least two implementations exist, clearly that has
helped the authors to work through the design decisions I commented on
above.

Section 14, Operational Considerations, works through the most important
of the decisions an Operator will need to make if they plan to implement
MRT-FRR - this seems very useful.

Overall, the draft is well-written and easy to read (apart from its
high acronym density), I believe it is 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