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 protected]] Sent: Saturday, January 02, 2016 7:10 AM To: [email protected] Cc: [email protected]; [email protected]; Janos Farkas <[email protected]> Subject: AD Review of draft-ietf-rtgwg-mrt-frr-algorithm-07 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.] ========================== [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: 1. I would put the Python code in an Appendix. [CB] Done.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
