Subject: AD Review of draft-ietf-rtgwg-mrt-frr-algorithm-07

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Sat, 2 Jan 2016 13:09:51 +0000

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.

---

From: Chris Bowers <[email-masked]>
Date: Sun, 10 Jan 2016 18:01:45 +0000

Alvaro,

Thanks for your detailed feedback.  I've posted  a new revision incorporating your comments.

The new revision is here.
https://www.ietf.org/internet-drafts/draft-ietf-rtgwg-mrt-frr-algorithm-08.txt

The diff is here.
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-mrt-frr-algorithm-08

See specific responses and text inline with [CB].

I also included links to diffs on github containing the XML edits addressing particular issues or set of issues.  They are intended to help in reviewing the edits, but refer to the version submitted for the latest definitive revision.

Thanks,
Chris

From: Alvaro Retana (aretana) [mailto:[email-masked]]
Sent: Saturday, January 02, 2016 7:10 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Janos Farkas <[email-masked]>
Subject: AD Review of draft-ietf-rtgwg-mrt-frr-algorithm-07

Hi!

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.]
==========================
[CB]  I created the operational considerations section (copied below).   Some material could go in either this or the Operational Considerations section of the architecture draft, so we could still shift items to or from that section.   I also removed the references to  [I-D.ietf-rtgwg-lfa-manageability] and made edits to have the text stand on its own.  The diff of changes addressing the above issues is:
https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/9a18f300dfddcc0829c980393f0e39eeb19b3813
10.  Operational Considerations

   This sections discusses operational considerations related to the the
   MRT Lowpoint algorithm and other potential MRT algorithm variants.
   For a discussion of operational considerations related to MRT-FRR in
   general, see the Operational Considerations section of
   [I-D.ietf-rtgwg-mrt-frr-architecture].

10.1.  GADAG Root Selection

   The Default MRT Profile uses the GADAG Root Selection Priority
   advertised by routers as the primary criterion for selecting the
   GADAG root.  It is RECOMMENDED that an operator designate a set of
   routers as good choices for selection as GADAG root by setting the
   GADAG Root Selection Priority for that set of routers to lower (more
   preferred) numerical values.  Criteria for making this designation
   are discussed below.

   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.

   If the router currently selected as GADAG root becomes unreachable in
   the IGP topology, then a new GADAG root will be selected.  Changing
   the GADAG root can change the overall structure of the GADAG as well
   the paths of the red and blue MRT trees built using that GADAG.  In
   order to minimize change in the associated red and blue MRT
   forwarding entries that can result from changing the GADAG root, it
   is RECOMMENDED that operators prioritize for selection as GADAG root
   those routers that are expected to consistently remain part of the
   IGP topology.

10.2.  Destination-rooted GADAGs

   The MRT Lowpoint algorithm constructs a single GADAG rooted at a
   single node selected as the GADAG root.  It is also possible to
   construct a different GADAG for each destination, with the GADAG
   rooted at the destination.  A router can compute the MRT-Red and MRT-
   Blue next-hops for that destination based on the GADAG rooted at that
   destination.  Building a different GADAG for each destination is
   computationally more expensive, but it may give somewhat shorter
   alternate paths.  Using destination-rooted GADAGs would require a new
   MRT profile to be created with a new MRT algorithm specification,
   since all routers in the MRT Island would need to use destination-
   rooted GADAGs.

===========================

  1.  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.
=============
[CB] Agreed.  Changes in this diff.
https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/d70e29a9d775f759b7ba21f4fcc8a9ddc3c55fc9
=============

  1.  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..).
=============
[CB]  Removal of references is done in this diff:
https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/87f2ca3e340d372dd46898a9f39de2a6bd7197c4
=============

  1.  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.
=============
[CB]  Done is this diff.
https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/561365b49d04c65f9b98313de88ded0520f71340
==============
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."
============================
[CB]  Done in diff below.  Also changed title to "An Algorithm" as opposed to "Algorithms" to focus on MRT Lowpoint algorithm.  I also changes several references to "algorithm" to "GADAG construction method" to avoid ambiguity.
https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/54c28c2206d7aa8844dd01fce9940fc15b323220
============================

  1.  Section 5. (Algorithm Sections)  s/This algorithm/The MRT Lowpoint algorithm
  2.  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.
============================
[CB] I changed the reference to 802.1Qca, where the normative reference is found in clause 45.3.3., and pointed out that the normative reference is there.  The goal is to have the normative reference only defined in one place.
Done in this diff.
https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/ef39e599f305713825aa9f65e4445478eec40a80

   The Interface_Compare function in Figure 14 relies on the

   interface.metric and the interface.neighbor.mrt_node_id values to

   order interfaces.  The exact source of these values for different

   IGPs and applications is specified in Figure 15.  The metric and

   mrt_node_id values for OSPFv2, OSPFv3, and IS-IS provided here is

   normative.  The metric and mrt_node_id values for ISIS-PCR in this

   table should be considered informational.  The normative values are

   specified in [IEEE8021Qca] .

============================

Nits:

[CB] Done.