An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)
draft-ietf-rtgwg-mrt-frr-algorithm-09

[Ballot comment]

- That's an awful lot of code to have zero new security
considerations associated with the spec. Go on - tell me: did
you really consider if there were some or not? :-)

- I don't think the secdir review [1] has yet gotten a
response. Nothing major there, but good to reply if you've
not already.

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06335.html

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-rtgwg-mrt-frr-algorithm-08.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: "Janos Farkas" , rtgwg-chairs@ietf.org, janos.farkas@ericsson.com, draft-ietf-rtgwg-mrt-frr-algorithm@ietf.org, aretana@cisco.com, rtgwg@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (An Algorithm for Computing Maximally Redundant Trees for IP/LDP Fast-Reroute) to Proposed Standard


The IESG has received a request from the Routing Area Working Group WG
(rtgwg) to consider the following document:
- 'An Algorithm for Computing Maximally Redundant Trees for IP/LDP Fast-
  Reroute'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-01-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-algorithm/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-algorithm/ballot/


No IPR declarations have been submitted directly on this I-D.

=== AD Review of draft-ietf-rtgwg-mrt-frr-algorithm-07 ===

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.