Early Review of draft-ietf-rtgwg-mrt-frr-architecture-09
review-ietf-rtgwg-mrt-frr-architecture-09-rtgdir-early-decraene-2016-02-01-00

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.