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.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
