Hi!
I just finished reviewing this document. I have several comments (below) that
I want to see addressed before starting the IETF Last Call.
As with draft-ietf-rtgwg-mrt-frr-architecture, my main point of concern is
related to operational/management considerations — the Architecture document
should carry the load of these considerations, but there are some that I think
are algorithm-specific and should be included here.
Thanks!
Alvaro.
Major:
1. Operational/Management Considerations
* Section 1. (Introduction): "This document defines an algorithm for
selecting an appropriate MRT alternate for consideration. Other alternates,
e.g. LFAs that are downstream paths, may be preferred when available and that
policy-based alternate selection process [I-D.ietf-rtgwg-lfa-manageability] is
not captured in this document." This paragraph seems to say that the criteria
in I-D.ietf-rtgwg-lfa-manageability applies also to the selection between MRT
alternates and others. Is that the intent?
* Later in Section 5.4. (Initialization) you mention the criteria in
I-D.ietf-rtgwg-lfa-manageability applied to MRT ("Due to FRR manageability
considerations [I-D.ietf-rtgwg-lfa-manageability], it may also be desirable to
administratively configure some interfaces as ineligible to carry MRT FRR
traffic.").
* I mention all this because I-D.ietf-rtgwg-lfa-manageability is
listed as an Informative Reference both in this document and in
draft-ietf-rtgwg-mrt-frr-architecture (where there's just a light mention of
manageability). If the criteria/recommendations in
I-D.ietf-rtgwg-lfa-manageability are to be followed, then I would like to see a
stronger statement about it. [There is a corresponding comment included in my
review of draft-ietf-rtgwg-mrt-frr-architecture.]
* I'm surprised that there are no Operational Considerations in this
document. I am hoping to see general considerations in
draft-ietf-rtgwg-mrt-frr-architecture, but some of the specifics are clearly
algorithm related — the resulting length of the alternate path, for example.
Please include an Operational Considerations section where some of the guidance
given in the document can be reflected, for example:
* Section 5.3. (GADAG Root Selection) "Analysis has shown that the
centrality of a router can have a significant impact on the lengths of the
alternate paths computed. Therefore, it is RECOMMENDED that off-line analysis
that considers the centrality of a router be used to help determine how good a
choice a particular router is for the role of GADAG root."
* Section 9. (Algorithm Alternatives and Evaluation) "In addition,
it is possible to calculate Destination-Rooted GADAG…Building GADAGs per
destination is computationally more expensive, but may give somewhat shorter
alternate paths. It may be useful for live-live multicast along MRTs."
* [[Minor] BTW, it looks like multicast is outside the scope of
draft-ietf-rtgwg-mrt-frr-architecture. That doesn't mean that the algorithm
may not be useful for it — but Section 9 is the only place that multicast is
mentioned.]
2. Section 3. (Terminology and Definitions) Not all the common terms
between this document and draft-ietf-rtgwg-mrt-frr-architecture are defined the
same way. Some differences are indeed small, but to avoid confusion and
misinterpretation please be consistent. Suggestion: include in this document
only the terms that were not present in draft-ietf-rtgwg-mrt-frr-architecture.
3. References to Extensions. This document describes an algorithm to be
used in the MRT Architecture..as such, please leave mention of the
extensions/specific solutions out — as those other drafts progress the picture
will be complete. Some pointers:
* All references to I-D.ietf-ospf-mrt and I-D.ietf-isis-mrt.
* Section 5.4. (Initialization): "This constraint MUST be consistently
flooded via the IGP [I-D.ietf-ospf-mrt] [I-D.ietf-isis-mrt]…so that links are
known to be MRT-ineligible…" I'm venturing to say that the requirement here
is for all the routers in the area/level/island to have this information, while
the specific mechanism (IGP flooding, magic central box, manual configuration,
etc.) is an implementation detail. I fully understand that IGP flooding may be
the best/obvious choice and that implementations are being worked in that
direction, but I think that's the job of the extension drafts (to indicate how
to meet the requirement with IGP flooding, or the magic box, or etc..).
4. Section 9.1. (Algorithm Evaluation) I am disappointed that you chose not
to focus this section on MRT Algorithm Alternatives and Evaluation, and instead
decided to compare MRT with solutions that don't provide complete coverage —
and kicked off the discussion precisely with the coverage (Figure 30). Please
remove the comparison to other technologies that are not potential MRT
algorithms.
* Later in the text you do get back to data specific to the Lowpoint
Algorithm and the ones described in the Appendixes.
Minor:
1. Other algorithms. In several places general statements about algorithms
for MRT are made — I'm assuming that you are referring to the algorithms
mentioned/considered in this document (and not making statements about other
yet-to-be-known algorithms), is that correct? If so, please be clear about it.
Here are some examples:
* 1. (Introduction): "Algorithms for computing MRTs can handle arbitrary
network topologies…"
* 4. (Algorithm Key Concepts): "There are five key concepts that are
critical for understanding…other algorithms for computing MRTs."
*
9. (Algorithm Alternatives and Evaluation) "This specification defines the MRT
Lowpoint Algorithm, which is one option among several possible MRT algorithms.
Other alternatives are described in the appendices."
2. Section 5. (Algorithm Sections) s/This algorithm/The MRT Lowpoint
algorithm
3. Section 5.1. (Interface Ordering)
* Why are the values in Figure 15 for ISIS-PCR not considered Normative?
* I'm a little bit confused because the Interface_Compare function
depends on the values; what happens if the values received are not the expected
ones? For ISIS-PRC, can I use some other source for those values?
* [I took a quick peek at draft-ietf-isis-pcr, but didn't find a
mention of MRT Node ID, for example.]
* The last paragraph in this Section seems superfluous to me as it
doesn't add/change anything.
Nits:
1. I would put the Python code in an Appendix.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
