+1
Stewart
On 21/01/2016 12:25, Pierre Francois (pifranco) wrote:
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)" <[email protected]
<mailto:[email protected]>>
Date: Thursday 14 January 2016 22:58
To: Chris Bowers <[email protected] <mailto:[email protected]>>,
"[email protected]
<mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>
Cc: "[email protected] <mailto:[email protected]>"
<[email protected] <mailto:[email protected]>>,
"[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
Subject: Re: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08
On 1/10/16, 12:16 PM, "Chris Bowers" <[email protected]
<mailto:[email protected]>> 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.
…
4. 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..
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
