Bruno, Thanks for the detailed comments. We have published a new revision incorporating your feedback, as well as some outstanding feedback from WG last call, AD review, and the IESG.
Htmlized: https://tools.ietf.org/html/draft-ietf-rtgwg-mrt-frr-architecture-10 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-mrt-frr-architecture-10 Specific comment are addressed below with [CB]. Thanks, Chris -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Friday, January 29, 2016 9:06 AM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: RtgDir review: draft-ietf-rtgwg-mrt-frr-architecture-09 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-rtgwg-mrt-frr-architecture-09.txt Reviewer: Bruno Decraene Review Date: 2016-01-29 IETF LC End Date: 2016-01-29 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Document is clear and very well written. Thank you. Very much appreciated given the size of the document and the subject. Majors Issues: None Minor Issues: ---- - section 6: Unicast forwarding with MRT and Fast-Reroute This section list many possibilities of what could have be done or what could be used. This is very interesting and open larger possibilities, but for a STD track document, it may have been more prescriptive. (and the last paragraph of §6.3.1.2 starting with "For completeness" further push the cursor on the side of catalog of possible solutions rather than the specification of a one STD track solution.) But I agree that the "MRT architecture" could be seen as broader than a single solution. And the document propose the definition of "MRT profiles" which seem appropriate to allow for interoperable deployments (but as a single profile is defined, it would have been possible to write a single solution, while still being extendable in the future). Eventually I would propose a slight change in the ToC for the reader to more easily understand what is optional vs required: :s/6.1 MRT Forwarding Mechanisms/6.1 Introduction to MRT Forwarding options Adding "6.2.4 Required suppport", using "6.3.3 Required support" as model (plus moving the last sentence of 6.2.3 in this section) [CB] Good idea. Changes implemented in: https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/e5f387c9cc1751475240b02e0b79861f4d84e318 ---- Comparison: [Note: Yes, I read that authors will remove the comparison table in the next version. :-) But I had started the review before, and I'm still reviewing the latest version.] I'm not sure that the comparison is best placed in the introduction section. I'd rather move it later in the doc, or in appendix and have the introduction only reference it. Or in a different draft. - 3rd column " The third column gives an estimate of the amount of computation required at each node to support the FRR method, in addition to the usual SPF computation rooted at the computing node itself. This metric of comparison is important for implementations that seek to quickly recompute repair paths" ok. But for regular routing, this time is typically driven by FIB update rather than control plane computation. Given that "the MRT Lowpoint algorithm is computationally efficient", it's not clear to me that control plane computation is the right metric to evaluate the time to be ready for the next failure. Especially since MRT requires a larger FIB (*3) and hence will be slower on the main factor. - MRT use a dedicated infrastructure (protocols extension, algorithm, RIB/FIB entries) for the FRR traffic. §14.1 recommends to check that this infrastructure is running correctly which represent an additional operational work and tooling. Other solutions e.g. LFA, TI-LFA, RLFA re-uses the nominal routing infrastructure which is already monitored. - Traffic capacity may be an interesting metric to compare (as discussed in §14.2) ========= [CB] As you noted, this table and text has been removed, but the feedback is useful in case the text ends up in another document at some point in the future. https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/7655acbd6f350b4505ab63a9b21e53582b913b04 ========= ---- §14.2 Traffic Capacity on Backup Paths Having not read MRT Low Point Algo, "Advertising links as MRT-Ineligible is the main tool provided by MRT-FRR for keeping backup traffic off of lower bandwidth links during fast-reroute events." "Main" or "Only"? If others tools are effective, it may be useful to indicate them. In particular, it's not obvious whether IGP cost is taken into account and may be useful to give preference to some backup path. If not, it may be useful to indicate that the backup path will not (significantly) take into account the IGP metrics (e.g. delay, bandwidth, distance, cost, operator preferences...) ========== [CB] I modified the text to read as below. The MRT Lowpoint algorithm produces a pair of diverse paths to each destination. These paths are generated by following the directed links on a common GADAG. The decision process for constructing the GADAG in the MRT Lowpoint algorithm takes into account individual IGP link metrics. At any given node, links are explored in order from lowest IGP metric to highest IGP metric. Additionally, the process for constructing the MRT-Red and Blue trees uses SPF traversals of the GADAG. Therefore, the IGP link metric values affect the computed backup paths. However, adjusting the IGP link metrics is not a generally applicable tool for modifying the MRT backup paths. Achieving a desired set of MRT backup paths by adjusting IGP metrics while at the same time maintaining the desired flow of traffic along the shortest paths is not possible in general. MRT-FRR allows an operator to exclude a link from the MRT Island, and thus the GADAG, by advertising it as MRT-Ineligible. Such a link will not be used on the MRT forwarding path for any destination. Advertising links as MRT-Ineligible is the main tool provided by MRT- FRR for keeping backup traffic off of lower bandwidth links during fast-reroute events. =========== --- "This document describes a solution for IP/LDP fast-reroute [RFC5714]. MRT-FRR creates two alternate trees separate from the primary next-hop forwarding used during stable operation." One of the tree may use the primary next-hop and hence is not that separate. ======== [CB] Changed "separate" to "distinct" and modified wording to clarify. Modifed text: MRT-FRR creates two alternate forwarding trees which are distinct from the primary next-hop forwarding used during stable operation. ======== --- "[TI-LFA] aims to provide" All FRR solutions "provides" will TI-LFA "aims to provide" ;-) Although TI-LFA is not a WG document, IMHO the document could use the same formulation for all FRR solutions. ======= [CB] Was in the now-deleted comparison section. ======= --- §1.1 "Asymmetric link costs are also a common aspect of networks. There are at least three common causes for them. First, any broadcast interface is represented by a pseudo-node and has asymmetric link costs to and from that pseudo-node. Second, when routers come up or a link with LDP comes up, it is recommended in [RFC5443] and [RFC6987] that the link metric be raised to the maximum cost; this may not be symmetric and for [RFC6987] is not expected to be. " Given the previous Figure 1, I assume that the target of the comment is TI-LFA link protection with 2 labels. In this case, 2 comments: - IINM, what is needed (for the proof) is symmetric cost between _forwarding_ nodes. Pseudo-node would not count/be an issue. - TI-LFA needs Segment Routing in which case LDP would not be used. Hence it does not seem fair to assume that LDP-IGP sync would be present. ======= [CB] I deleted this paragraph. ======= --- "When a network needs to use a micro-loop prevention mechanism [RFC5715] such as Ordered FIB[RFC6976] or Nearside Tunneling[RFC5715], then the whole IGP area needs to have alternates available" I would propose "When a network to use Ordered FIB[RFC6976] or Nearside Tunneling[RFC5715] as a micro-loop prevention mechanism [RFC5715], then the whole IGP area needs to have alternates available" Motivation: the requirement for FRR comes from these 2 specific solutions, not from "a micro-loop prevention mechanism". I won't argue whether the original text is fine from an english standpoint (as it well beyond my skills), but one reader could misinterpret it. ============= [CB] Agreed. Changes in: https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/d6031ba6ccf210cfc24a90c55d08c80773000541 ============= --- "ADAG: Almost Directed Acyclic Graph - a graph that, if all links incoming to the root were removed, would be a DAG." It's not clear to me what "the root" is. It seems to refer to "a graph" and I can't find how this root is determined. May be you mean :s/graph/DAG but even in this case, it's not obvious to me that there is a single "root". (sorry if this is obvious for everyone else. No need to explain it to me. I'm just checking that this is well defined) ============== [CB] Good catch. I hope this version is more clear. ADAG: Almost Directed Acyclic Graph - a graph with one node designated as the root. The graph has the property that if all links incoming to the root were removed, then resulting graph would be a DAG. ============== --- §6.1.1.1 "However, it reduces the label space for other uses, and it increases the memory needed to store the labels and the communication required by LDP to distribute FEC-label bindings." It also increase the time needed to install the FRR entries in the FIB hence the time needed before the next failure may be protected. ======== [CB] Added the following text. In general, this approach will also increase the time needed to install the FRR entries in the FIB and hence the time needed before the next failure can be protected. ======== --- [RFC7307] (LDP MT) is mandatory to implement for both LDP and IP traffic. It may eventually be seen as a _normative_ reference. [CB] Changed RFC7307 to normative. Also took the opportunity to move RFC5286 to informative. --- "All routers in an MRT Island MUST support the same MRT profile." ok, but IMHO this is more a matter of definition than a matter of behavior that MUST be enforced. So I would rather have a definition of an MRT Island. (e.g. An MRT Island is defined as the set of routers supporting the same MRT profile, in the same IGP area/level and the bi-directionals links interconnecting those routers,". ============ [CB] Good point. I made the following changes At a high level, an MRT Island is defined as the set of routers supporting the same MRT profile, in the same IGP area/level and the bi-directional links interconnecting those routers. More detailed descriptions of these criteria are given below. 7.1. IGP Area or Level All links in an MRT Island are bidirectional and belong to the same IGP area or level. ...... 7.2. Support for a specific MRT profile All routers in an MRT Island support the same MRT profile. ....... ============ --- § 7.2 "A given router can support multiple MRT profiles and participate in multiple MRT Islands." [...] "Note that a router may advertise support for multiple different MRT profiles." IMHO the second sentence is redundant and could be removed. ===== [CB] Agreed. ===== --- §8.3 "the most preferred GADAG Root Selection Priority advertised (corresponding to the lowest numerical value of GADAG Root Selection Priority)" Do you mean that the _most preferred_ is the node advertising the _lowest priority_? This does not seem intuitive to me. If so, IMHO this should be specified clearly somewhere, not just between brackets. But I would rather favoring a intuitive behavior (e.g. if lowest numerical value is prefered, use the word "Cost" or "Metric" rather than "Priority". If "Priority" is kept, prefer the highest value. ============= [CB] I agree that this is counter-intuitive. I looked into changing this a while back, but I stopped when I found other examples of lower numerical priority values being used to indicate higher preference. RFC 3209 (RSVP-TE) uses this convention for setup priority for RSVP LSPs. 802.1D (spanning tree) uses it for bridge priority. I think that changing the actual ordering in the algorithm at this point in not a good idea since it will create confusion. I am not opposed to changing the name, but I would also need to propagate that change into the algorithm draft text, pseudo-code, and Python implementation, so if we change the name, I only want do it once. Somehow "cost" and "metric" don’t seem like good options because there is already the IGP cost or metric in this problem domain. Also costs and metrics are typically cumulative, whereas this is not. My preference at this point would be for something neutral like "GADAG Root Selection Number" or "GADAG Root Selection Value" so that the user is not misled into making assumptions about how the value is used. Another option would be "GADAG Root Selection Penalty". For the moment, I've tried to address potential confusion while leaving the name the same with the text below, but would appreciate feedback on the above suggestion as well. GADAG Root Selection Policy: Among the routers in the MRT Island with the lowest numerical value advertised for GADAG Root Selection Priority, an implementation MUST pick the router with the highest Router ID to be the GADAG root. Note that a lower numerical value for GADAG Root Selection Priority indicates a higher preference for selection. ============= -- §6.1.1.4 "If a router supports a profile that includes the MRT LDP Label option for MRT transit forwarding mechanism, then it MUST support option 1A, which encodes topology-scoped FECs using a single label." ok. But in this condition, I'm not sure to see a reason why anyone would implement option 1B in addition. In which case, it may have simplified the spec to just move option 1B in appendix and hence remove MRT LDP label options. ======= [CB] I modified the existing text to clarify the reasoning. The main changes and added text are copied below, but see this github diff for the complete set of changes. https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/0f7de23b50aae054daa17ae62a40e5366c669caf 6.1.1.3. Compatibility of MRT LDP Label Options 1A and 1B MRT transit forwarding based on MRT LDP Label options 1A and 1B can coexist in the same network, with a packet being forwarded along a single MRT path using the single label of option 1A for some hops and the two label stack of option 1B for other hops. However, to simplify the process of MRT Island formation we require that all routers in the MRT Island support at least one common forwarding mechanism. As an example, the Default MRT Profile requires support for the MRT LDP Label Option 1A forwarding mechanism. This ensures that the routers in an MRT island supporting the Default MRT Profile will be able to establish MRT forwarding paths based on MRT LDP Label Option 1A. However, an implementation supporting Option 1A may also support Option 1B. If the scaling or performance characteristics for the two options differ in this implementation, then it may be desirable for a pair of adjacent routers to use Option 1B labels instead of the Option 1A labels. If those routers successfully negotiate the use of Option 1B labels, they are free to use them. This can occur without any of the other routers in the MRT Island being made aware of it. Note that this document only defines the Default MRT Profile which requires support for the MRT LDP Label Option 1A forwarding mechanism. 6.1.1.4. Required support for MRT LDP Label options If a router supports a profile that includes the MRT LDP Label Option 1A for the MRT transit forwarding mechanism, then it MUST support option 1A, which encodes topology-scoped FECs using a single label. The router MAY also support option 1B. If a router supports a profile that includes the MRT LDP Label Option 1B for the MRT transit forwarding mechanism, then it MUST support option 1B, which encodes the topology and FEC using a two label stack. The router MAY also support option 1A. ====================== -- §10 "Second, this allows failures that might appear in multiple areas (e.g. ABR/LBR failures) to be separately identified and repaired around. Third, the packet can be fast-rerouted again, if necessary, due to a failure in a different area." It's not obvious to me why the second and third reasons are really different. ========== [CB] Rewrote the following text to clarify. Second, this allows a single router failure that manifests itself in multiple areas (as would be the case with an ABR/LBR failure) to be separately identified and repaired around. Third, the packet can be fast-rerouted again, if necessary, due to a second distinct failure in a different area. =========== --- §10 " An ABR/LBR that receives a packet on MRT-Red or MRT-Blue towards destination Z should continue to forward the packet along MRT-Red or MRT-Blue only if the best route to Z is in the same area as the interface that the packet was received on. This seems a bit OSPF specific. What about IS-IS? In particular when some routers may be in both levels. Idem in §10.1: " To those routers in the same area as the best route to the destination, the ABR/LBR advertises the following FEC-label bindings:" How do this apply to IS-IS LBR? ========== [CB] I created an appendix to explicitly describe the IS-IS inter-level forwarding behavior. Please see the latest draft for that appendix. ========== --- "The use of the Rainbow-FEC by the ABR for non-best-area advertisements is RECOMMENDED." I don't see the basis for this recommendation. This choice seems driven by specific implementations. Other implementations may have no reason to send the Rainbow-FEC. IMO, it would be enough to say "a router that supports the LDP Label MRT Forwarding Mechanism MUST be able to receive and correctly interpret the Rainbow-FEC." which is already said. Hence I would propose: OLD: The use of the Rainbow-FEC by the ABR for non-best-area advertisements is RECOMMENDED. An ABR MAY advertise the label for the default topology in separate MRT-Blue and MRT-Red advertisements. However, a router NEW: An ABR may choose to either advertise the Rainbow-FEC or advertise separate MRT-Blue and MRT-Red advertisements. This is a local choice. A router In which case, section 10.1 would need to be updated to reflect this. ======== [CB] Agreed. Changes captured in this diff. https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/e884e226f72560721a2ab338822489939866b3c7 ======== --- §16 IANA In draft-haas-code-point-reservation-bcp, Jeff proposed to reserve the last code point (255) to allow for future extension. While I'm not sure this would be needed for MRT profiles, this would also cause no harm. ========= [CB] Good point. Addressed here. https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/1445514eaade76e7a8605eaae18780e69e127ead ========= Nits: - LFA imposes no additional labels imposed too many "impose"? - :s/ISIS/IS-IS - :s/implmentations/implementations ============== [CB] Agreed. ============== _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
