Re: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08

["Pierre Francois (pifranco)" <[e-mail]>]

Hello everyone,


I would tend to agree with Alvaro on the fact that the comparison table should

completely disappear from the work. More generally, comparison with other

solutions should not be present in this draft, at all.


The reason is that the points of comparison currently featured in the draft

look quite incomplete, not taking some aspects stemming from requirements and experience with

FRR into account, or not discussing them deeply enough, giving the unnecessary

feeling of a biased analysis.


Adapting the draft to provide a completely thorough comparison would require a

substantial amount of work. Given the state of advancement of the draft, I

would find it unfortunate to start such a lengthy process here and delay the

draft further.


To me, the results of such an interesting comparison work should go in a

separate document fully dedicated to this task.


Cheers,


Pierre.


From: "Alvaro Retana (aretana)" <[e-mail]<mailto:[e-mail]>>
Date: Thursday 14 January 2016 22:58
To: Chris Bowers <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08

On 1/10/16, 12:16 PM, "Chris Bowers" <[e-mail]<mailto:[e-mail]>> wrote:

Chris:

Hi!

Thanks for the work in addressing my comments.  I just have a couple of minor comments (below).  I will start the IETF Last Call.

Thanks!

Alvaro.


…
Major:

  1.  In general, I feel uncomfortable with documents making value statements related, for example, to how they perform against different solutions.  The purpose of this document should be to describe the technology, not to compare against other solutions — that work (if wanted/needed) should be done in a different document.  Please remove comparisons to other technology and relative statements.  Some examples:

  *   Abstract: "MRT is also extremely computationally efficient…computation is less than the LFA computation..."  As was expressed on the list, maybe CPU cycles are not that important if compared to other aspects…
  *   Introduction: "Other existing or proposed solutions are partial solutions or have significant issues, as described below."  It is ok to describe other solutions, but please limit the description to the facts.

  *   About the table: there are obviously other columns that could have been included, which means that the table is not complete.

==========
[CB]  The abstract and introduction have been significantly revised to try to remove value statements.  I modified the comparison table and added several columns, trying to provide a factual comparison of tradeoffs based on different metrics without making value judgements.   (See the revised document or main diff above.)  However, I am also willing to simply remove the table and descriptions, if that makes more sense.
==========

I am not crazy about the table.   The added columns make it a little better, but even if there are no judgements people will read into it..

I think Stewart had commented on it as well — I would like to see his opinion as well.

…

  1.  Operations/Management Considerations

  *   Given that the MRT paths don't follow the shortest paths, or even potentially planned backup paths in the network, I think you should include something about the potential impact related to capacity planning, congestion, stretch, etc.
  *   What about address management?  Are there considerations about assignment and management for the additional loopbacks required for IP tunnels?
  *   Section 15. (Applying Policy to Select from Multiple Possible Alternates for FRR) basically says that policy can be applied "to select the best alternate from those provided by MRT and other FRR technologies".  You're right to point out that "[I-D.ietf-rtgwg-lfa-manageability] discusses many of the potential criteria that one might take into account when evaluating different alternates for selection".  What are the considerations that should be taken into account when comparing between MRT and others?  Are the criteria and requirements outlined in I-D.ietf-rtgwg-lfa-manageability applicable?  Even though I-D.ietf-rtgwg-lfa-manageability is intended to be LFA-specific, should it be a Normative reference? [Note that there's a similar comment related to  I-D.ietf-rtgwg-lfa-manageability in my review of draft-ietf-rtgwg-mrt-frr-algorithm.]
  *   Applicability/Guidance for Operators

  *   Section 4. (Maximally Redundant Trees (MRT)) clearly explains about the impact of not having a 2-connected network for MRT to be applicable.  Section 11.3. (MRT Alternates for Destinations Outside the MRT Island) talks about partial implementation in an area.
  *   I think it would be important to consolidate some of that guidance (there's probably more) in a single place.  Note that I'm not looking for a 30 page extension (a la RFC6571), just some general guidance.

  *   Given that both Sections 14 and 15 were added just in the latest version of the document, please consider taking a look at RFC5706.
  *   [Nit] Consider making Section 15. (Applying Policy to Select from Multiple Possible Alternates for FRR) a sub-section of Section 14. (Operations and Management Considerations).

==========
[CB] These changes are shown in this diff:
https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/c361f37638390a1b0364d67726367aabef203976

After those changes it looks like the reference to I-D.ietf-rtgwg-lfa-manageability is no longer needed.

…
   We note that the computations in [I-D.ietf-rtgwg-mrt-frr-algorithm]

Just taking advantage of this text to say that you may want to edit away the use of "we" in the text.  "We" who?  Most of the statements may be clearer in the third person.  Just a style nit..