Subject: Benoit Claise's No Objection on draft-ietf-rtgwg-mrt-frr-architecture-09: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 04 Feb 2016 02:36:26 -0800

Benoit Claise has entered the following ballot position for
draft-ietf-rtgwg-mrt-frr-architecture-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-architecture/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

We're lucky to have two OPS DIR reviews for this document.

>From Fred Baker:

In my view, although I have concerns as I am about to state, I consider
the draft to be ready for IESG review and potential publication as an RFC
at Proposed Standard. I have no specific issues I would like to see
addressed, nor do I believe the technology or draft to be fundamentally
flawed.

Speaking in general terms, this draft describes a solution for the
problem posed in RFC 5714, which is to say a solution for fast reroute in
a network whose routing is implemented using IS-IS and LDP. It is not the
only possible solution. In terms of graph theory, we might define a
"connected graph" as a set of "nodes" and a set of "links" that
interconnect them, such that every node is connected via some sequence of
links and nodes to each of the other nodes in the connected graph. The
Maximally Redundant Tree model seeks to divide the connected graph into
two or more connected sub-graphs, each of which connects the same set of
nodes, but using sets of interconnecting links whose intersection set is
null, or is at least minimized. In the event that a link in one connected
sub-graph fails, the network can continue to use another connected
sub-graph to guide routing during the outage.

There are obvious degenerate cases, in which the sets of links in
sub-graphs are forced to overlap to some degree, or some nodes are not
found in all sub-graphs. Part of the architecture is designed to identify
those cases (which might occur, for example, in the presence of multiple
simultaneous failures, or when the network is inherently deficient for
reasons unrelated to and perhaps in violation of the mathematics) and
handle them as best it can.

As one might imagine, this is not trivial. My first comment on reading
the architecture (and on reading the algorithm, which is a separate
document) is that the algorithm is complex, and therefore (like anything
that is complex) prone to errors and failures of various kinds, and
potentially has failure modes that have not yet been detected. This is
not to be considered as a strike against it, but a point of caution; the
operator using the approach wants to ensure that s/he has the tools
necessary to monitor network health, and to quickly discover and correct
errors if and when they occur. The algorithm draft contains several
proofs of correctness for various parts or in various cases, and refers
to papers containing such proofs, with the intent of minimizing the
inherent risk. That said, to my knowledge there is not a global proof of
correctness, as there is for example in the Shortest Path First algorithm
or other algorithms used in the network. The risk is therefore not zero.

>From the perspective of the IETF, that is precisely the reason a protocol
like this should be used operationally at the Proposed Standard level,
updated as needed, and ultimately re-released as an Internet Standard
when the algorithm and implementations have been operationally proven.

With that introduction, the first question in my mind is whether the
description is such that two implementors are likely to be able to
implement interoperable implementations, or whether ambiguities or lack
of clarity would prevent that. This draft identifies two proprietary
prototype implementations, by Huawei and Juniper, which if they are
interoperable would address the question to a considerable degree. The
draft does not, however, describe interoperability testing between them,
which at least suggests that this might be yet future. On this score,
given the complexity of the design, I personally would be greatly
comforted by a test report along the lines of RFC 1246. Since such tests
usually find text that needs tweaking, I might suggest that the
publication at RFC be delayed until such testing can be performed and the
lessons learned, whatever they are, incorporated in the documents.
Failing that, experience leads me to believe that there will be
subsequent documents that update or obsolete these.

The corollary question in my mind is whether an operator reading the
architecture will be able to figure out how to effectively use it. On
this score, I give the draft a thumbs-up. It is well written, the various
issues are raised and dealt with, and the ramifications are in my view
clear.

Now the review from Nevil Brownlee:

This is a long draft, presenting the MRT-FRR architecture, and exploring
in some detail the design alternatives that were possible during that
process.

There are many acronyms used throughout the draft, that will work well

for routers familiar with Routing in general, and MPLS in particular.
Others will find it useful to keep a browser window at hand!  For me,
PLR (Point of Local Repair) was new.

In section 11.1, the equations that test whether a path is loop-free
for nodes S and F use D_opt() as an abbreviation for Distance_opt()
[RFC 5286] - I understand the authors wish to get these equations onto
single lines, but the phrase "where D_opt() means Distance_opt()" would
be helpful.

Throughout the draft the phrase "protocol extensions to .. will be
defined elsewhere" appears, similarly the IANA Considerations section
defines an MPLS Multi-Topology Identifiers Registry, but says that
codepoints in it will be defined elsewhere.  Clearly this draft is
the first in what will become a cluster of RFCs.

On the Operations side of things, section 1.2 notes that "MRT-FRR
supports partial deployment."  That will allow Operators to deploy
it in stages (one MRT Island at a time?).

Further, several sections consider the possibility of "link-protecting
alternates causing route looping," it seems that MRT-FRR should remain
loop-free.

Section 13, Implementation Status [to be removed by the RFC Editor],
demonstrates that at least two implementations exist, clearly that has
helped the authors to work through the design decisions I commented on
above.

Section 14, Operational Considerations, works through the most important
of the decisions an Operator will need to make if they plan to implement
MRT-FRR - this seems very useful.

Overall, the draft is well-written and easy to read (apart from its
high acronym density), I believe it is ready for publication as an RFC.

---

From: Chris Bowers <[email-masked]>
Date: Sat, 6 Feb 2016 01:24:08 +0000

Benoit, Fred, and Nevil,

Thanks for the feedback.

With respect to the comment regarding the use of D_opt() from RFC5286,   I add the text below to clarify.

===============

   In the inequalities below, D_opt(X,Y)
   means the shortest distance from node X to node Y, and D_opt(X,p)
   means the shortest distance from node X to prefix p.

=============

This is incorporated in the latest version.
https://tools.ietf.org/html/draft-ietf-rtgwg-mrt-frr-architecture-10
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-mrt-frr-architecture-10

Thanks,
Chris

-----Original Message-----
From: Benoit Claise [mailto:[email-masked]] 
Sent: Thursday, February 04, 2016 4:36 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; Janos Farkas <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Benoit Claise's No Objection on draft-ietf-rtgwg-mrt-frr-architecture-09: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

>From Fred Baker:

In my view, although I have concerns as I am about to state, I consider the draft to be ready for IESG review and potential publication as an RFC at Proposed Standard. I have no specific issues I would like to see addressed, nor do I believe the technology or draft to be fundamentally flawed.

Speaking in general terms, this draft describes a solution for the problem posed in RFC 5714, which is to say a solution for fast reroute in a network whose routing is implemented using IS-IS and LDP. It is not the only possible solution. In terms of graph theory, we might define a "connected graph" as a set of "nodes" and a set of "links" that interconnect them, such that every node is connected via some sequence of links and nodes to each of the other nodes in the connected graph. The Maximally Redundant Tree model seeks to divide the connected graph into two or more connected sub-graphs, each of which connects the same set of nodes, but using sets of interconnecting links whose intersection set is null, or is at least minimized. In the event that a link in one connected sub-graph fails, the network can continue to use another connected sub-graph to guide routing during the outage.

There are obvious degenerate cases, in which the sets of links in sub-graphs are forced to overlap to some degree, or some nodes are not found in all sub-graphs. Part of the architecture is designed to identify those cases (which might occur, for example, in the presence of multiple simultaneous failures, or when the network is inherently deficient for reasons unrelated to and perhaps in violation of the mathematics) and handle them as best it can.

As one might imagine, this is not trivial. My first comment on reading the architecture (and on reading the algorithm, which is a separate
document) is that the algorithm is complex, and therefore (like anything that is complex) prone to errors and failures of various kinds, and potentially has failure modes that have not yet been detected. This is not to be considered as a strike against it, but a point of caution; the operator using the approach wants to ensure that s/he has the tools necessary to monitor network health, and to quickly discover and correct errors if and when they occur. The algorithm draft contains several proofs of correctness for various parts or in various cases, and refers to papers containing such proofs, with the intent of minimizing the inherent risk. That said, to my knowledge there is not a global proof of correctness, as there is for example in the Shortest Path First algorithm or other algorithms used in the network. The risk is therefore not zero.

>From the perspective of the IETF, that is precisely the reason a 
like this should be used operationally at the Proposed Standard level, updated as needed, and ultimately re-released as an Internet Standard when the algorithm and implementations have been operationally proven.

With that introduction, the first question in my mind is whether the description is such that two implementors are likely to be able to implement interoperable implementations, or whether ambiguities or lack of clarity would prevent that. This draft identifies two proprietary prototype implementations, by Huawei and Juniper, which if they are interoperable would address the question to a considerable degree. The draft does not, however, describe interoperability testing between them, which at least suggests that this might be yet future. On this score, given the complexity of the design, I personally would be greatly comforted by a test report along the lines of RFC 1246. Since such tests usually find text that needs tweaking, I might suggest that the publication at RFC be delayed until such testing can be performed and the lessons learned, whatever they are, incorporated in the documents.
Failing that, experience leads me to believe that there will be subsequent documents that update or obsolete these.

The corollary question in my mind is whether an operator reading the architecture will be able to figure out how to effectively use it. On this score, I give the draft a thumbs-up. It is well written, the various issues are raised and dealt with, and the ramifications are in my view clear.

This is a long draft, presenting the MRT-FRR architecture, and exploring in some detail the design alternatives that were possible during that process.

for routers familiar with Routing in general, and MPLS in particular.
Others will find it useful to keep a browser window at hand!  For me, PLR (Point of Local Repair) was new.

In section 11.1, the equations that test whether a path is loop-free for nodes S and F use D_opt() as an abbreviation for Distance_opt() [RFC 5286] - I understand the authors wish to get these equations onto single lines, but the phrase "where D_opt() means Distance_opt()" would be helpful.

Throughout the draft the phrase "protocol extensions to .. will be defined elsewhere" appears, similarly the IANA Considerations section defines an MPLS Multi-Topology Identifiers Registry, but says that codepoints in it will be defined elsewhere.  Clearly this draft is the first in what will become a cluster of RFCs.

On the Operations side of things, section 1.2 notes that "MRT-FRR supports partial deployment."  That will allow Operators to deploy it in stages (one MRT Island at a time?).

Further, several sections consider the possibility of "link-protecting alternates causing route looping," it seems that MRT-FRR should remain loop-free.

Section 13, Implementation Status [to be removed by the RFC Editor], demonstrates that at least two implementations exist, clearly that has helped the authors to work through the design decisions I commented on above.

Section 14, Operational Considerations, works through the most important of the decisions an Operator will need to make if they plan to implement MRT-FRR - this seems very useful.

Overall, the draft is well-written and easy to read (apart from its high acronym density), I believe it is ready for publication as an RFC.