Subject: RtgDir review: draft-ietf-rtgwg-mrt-frr-architecture-09

From: <[email-masked]>
Date: Fri, 29 Jan 2016 15:05:58 +0000

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)

----
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)

----
§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...)
---
"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.
---
"[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.
---
§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.
---
"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.
---
"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)
---
§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.
---
[RFC7307] (LDP MT) is mandatory to implement for both LDP and IP traffic. It may eventually be seen as a _normative_ reference. 
---
"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,".
---
§ 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.
---
§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.  
--
§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.
--
§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.
---
§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? 
---
 "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.   
---
§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.

Nits:
- LFA imposes no additional labels imposed
too many "impose"?
- :s/ISIS/IS-IS
- :s/implmentations/implementations

_________________________________________________________________________________________________________________________

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.