An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)
draft-ietf-rtgwg-mrt-frr-architecture-10

[Ballot comment]

- abstract: "IP/LDP" is a bit ambiguous - it could be read as
"IP over LDP," "IP and LDP" or "IP or LDP" not all of which
make sense I guess:-) Be better if the abstract said "IP and
LDP" I think.

- section 3: the definitions are very dense - would re-ordering
them help maybe? Not sure myself, but maybe think about
it.

- Section 8: with so many parameters, why choose an 8-bit
profile ID? That seems to be a bit short-sighted maybe?

- 12.2: The sequence presented here has the look of something
that might be a potential DoS vector, but maybe the
computation isn't that significant, not sure.  Did you
consider a potential attack where the bad actor takes down
then re-instates one or more links so as to increase the
computation to the max? (Perhaps you did and the max is still
not a big deal.)

- As noted by the secdir review [1] this is highly acronym
laden. I'd encourage an editing pass to try reduce that where
possible. I'll also bet a beer that not every acronym used is
either expanded or else present in the list of "well known"
acronyms (which is of course pretty outdated).

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06344.html

[Ballot 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.

[Ballot comment]
The IANA Considerations section creates a new registry for the MRT Profiles. It allocates "Values 221-255 are for vendor private use." Are there limitations/guidance on how vendors use this range? Should Section 8,14 or 17 say something about dealing with these ranges in operational networks?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-rtgwg-mrt-frr-architecture-09.txt. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document there is a single action which IANA is required to complete.

IANA is to create a registry entitled "MRT Profile Identifier Registry".

IANA QUESTION -> Where should this new registry be located? Is it a néw registry on the IANA Matrix or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained?

IANA QUESTION -> Are the fields in the registry the MRT Profile Number, a Description, and a Reference? Are there any other fields in the new registry?

The registration rules for the new registry are as follows: values 1-200 are assigned by Standards Action; values 201-220 are for experimentation; and values 221-255 are for vendor private use. All as defined by RFC 5226.

IANA understands that there is a single, initial value in the new registry:

MRT Profile ID: 0
Description: Default MRT Profile
Reference: [ RFC-to-be ]

IANA understands that the creation of this new registry is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: "Janos Farkas" , rtgwg-chairs@ietf.org, janos.farkas@ericsson.com, draft-ietf-rtgwg-mrt-frr-architecture@ietf.org, aretana@cisco.com, rtgwg@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees) to Proposed Standard


The IESG has received a request from the Routing Area Working Group WG
(rtgwg) to consider the following document:
- 'An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant
  Trees'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-01-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines the architecture for IP/LDP Fast-Reroute using
  Maximally Redundant Trees (MRT-FRR).  MRT-FRR is a technology that
  gives link-protection and node-protection with 100% coverage in any
  network topology that is still connected after the failure.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-architecture/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-architecture/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/1801/
  https://datatracker.ietf.org/ipr/1594/
  https://datatracker.ietf.org/ipr/1733/

=== AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 ===

I just finished reviewing this document.  I have several comments (please see below) that I want to see addressed before starting the IETF Last Call.

Out of the items marked as Major, the one that concerns me the most is the one related to Operations/Management Considerations.  It is surprising to me that such extensive work in the Standards Track didn't have any Operations/Management (or even Security!) Considerations until the current version.  My comments below echo some of the opinions on the list, but I can't claim that they are all inclusive.  As I pointed out below, I am not looking for a dissertation on the topic, but much more than what's there should be included.

Thanks!

Alvaro.


Major:

1. In general, I feel uncomfortable with documents making value statements related, for example, to how they perform against different solutions.  The purpose of this document should be to describe the technology, not to compare against other solutions — that work (if wanted/needed) should be done in a different document.  Please remove comparisons to other technology and relative statements.  Some examples:

* Abstract: "MRT is also extremely computationally efficient…computation is less than the LFA computation..."  As was expressed on the list, maybe CPU cycles are not that important if compared to other aspects…
* Introduction: "Other existing or proposed solutions are partial solutions or have significant issues, as described below."  It is ok to describe other solutions, but please limit the description to the facts.
** About the table: there are obviously other columns that could have been included, which means that the table is not complete.
* Section 4: "Modeling results comparing the alternate path lengths obtained with MRT to other approaches are described in [I-D.ietf-rtgwg-mrt-frr-algorithm]."  I am also including the corresponding comment in my review of that other document.
* Section 5: "is an advantage of using MRT"  In this case, at least a reference to Section 15. (Applying Policy to Select from Multiple Possible Alternates for FRR) might be in order.

2. References to Extensions.  This document being where the architecture for MRT is defined should set the stage/define requirements for extensions that are to be defined elsewhere, and not concern itself with the solutions themselves.  In other words, please remove references to where solutions (in the form of extensions) are being specified.  Some pointers:

* All references to I-D.ietf-ospf-mrt, I-D.ietf-isis-mrt and I-D.ietf-mpls-ldp-mrt, except maybe the ones in Section 13. (Implementation Status).
* There are two places where it is mentioned that the capabilities to advertise additional loopbacks "have not been defined".
* Section 7. (MRT Island Formation) starts by talking about the "purpose of communicating support for MRT in the IGP" which is the first time in the document that is mentioned.  While distribution with an IGP may be the obvious mechanism, please describe the requirement.
* Another example of the same occurs in Section 8.2. (Router-specific MRT paramaters) where it says that "additional router-specific MRT parameters may need to be distributed via the IGP", when I think the requirement is that these additional parameters need to be known by all routers in the MRT Island. [Again, distribution using the
IGP may be the obvious choice..]


3. Algorithm.  draft-ietf-rtgwg-mrt-frr-algorithm says that it "defines the…algorithm that is used in the default MRT profile".  Please make the text in this document consistent with that when referring to draft-ietf-rtgwg-mrt-frr-algorithm.  Some descriptions used in the text: "the exact MRT algorithm", "the algorithm to compute MRTs", "Example algorithm"

4. Operations/Management Considerations

* Given that the MRT paths don't follow the shortest paths, or even potentially planned backup paths in the network, I think you should include something about the potential impact related to capacity planning, congestion, stretch, etc.
* What about address management?  Are there considerations about assignment and management for the additional loopbacks required for IP tunnels?
* Section 15. (Applying Policy to Select from Multiple Possible Alternates for FRR) basically says that policy can be applied "to select the best alternate from those provided by MRT and other FRR technologies".  You're right to point out that "[I-D.ietf-rtgwg-lfa-manageability] discusses many of the potential criteria that one might take into account when evaluating different alternates for selection".  What are the considerations that should be taken into account when comparing between MRT and others?  Are the criteria and requirements outlined in I-D.ietf-rtgwg-lfa-manageability applicable?  Even though I-D.ietf-rtgwg-lfa-manageability is intended to be LFA-specific, should it be
a Normative reference? [Note that there's a similar comment related to  I-D.ietf-rtgwg-lfa-manageability in my review of draft-ietf-rtgwg-mrt-frr-algorithm.]
* Applicability/Guidance for Operators
** Section 4. (Maximally Redundant Trees (MRT)) clearly explains about the impact of not having a 2-connected network for MRT to be applicable.  Section 11.3. (MRT Alternates for Destinations Outside the MRT Island) talks about partial implementation in an area. 
** I think it would be important to consolidate some of that guidance (there's probably more) in a single place.  Note that I'm not looking for a 30 page extension (a la RFC6571), just some general guidance.
* Given that both Sections 14 and 15 were added just in the latest version of the document, please consider taking a look at RFC5706.
* [Nit] Consider making Section 15. (Applying Policy to Select from Multiple Possible Alternates for FRR) a sub-section of Section 14. (Operations and Management Considerations).


5. MRT Profile Selection and Algorithm Transition:
* From Section 7.2. (Support for a specific MRT profile): "All routers in an MRT Island MUST support the same MRT profile"…and…"A given router can support multiple MRT
profiles and participate in multiple MRT Islands.".  If I understand this correctly, routers can support multiple MRT profiles for the same area/level, right?  If so, how do the routers in the area/level agree on which profile will be the one supported? 
** Also, Section 8.1. (MRT Profile Options) says that "If a router advertises support for multiple MRT profiles, then it MUST create the transit forwarding topologies for each…"
  Are these multiple profiles inside the same area/level?  These two pieces of text don't seem to be in sync.  [But I may be missing something somewhere.]
* MRT Algorithm Transition: How is it done?  In Section 8.1. (MRT Profile Options) says that "Algorithm transitions
can be managed by advertising multiple MRT profiles", but there's no explanation of how.  This comment is related to the one above about MRT Profile Selection.
* [Minor] I may have missed this somewhere.. 
** The MRT MPLS MT-ID value is associated with the MRT profile, so that (for example) the MRT-Red MPLS MT-ID for the default profile is 3997, right?  If so, how does one introduce a new profile?  I'm guessing that by registering new MT-ID values.
** What happens if the MT-ID for the Red and Blue MRTs don't correspond to the same profile?

6. Section 17. (IANA Considerations) talks about the "MRT Profile TLV", which is not defined anywhere in this document.  I think that asking for the registry creation is enough.

7. Section 18. (Security Considerations)  Even though I don't think this document should make explicit references to extensions, clearly there will be a transport that needs to be secured: authentication, privacy, etc.

8. References: RFC2119 should be Normative.


Minor:

1. Section 1. (Introduction) says that: "Once traffic has been moved to one of MRTs, it is not subject to further repair actions. Thus, the traffic will not loop even if a worse failure (e.g. node) occurs when protection was only available for a simpler failure (e.g. link)."  I'm sure you mean that the worse failure occurs in the original topology (not in the MRT).  Please clarify.

2. Multicast protection is out of scope, right?  There's a reference to I-D.atlas-rtgwg-mrt-mc-arch in the Introduction (which is fine), but not explicit indication of the scope.  Section 8.1. (MRT Profile Options) also talks about multicast then describing "MRT Forwarding Mechanism" ("The None option in may be useful for multicast global protection.").
* In Section 8.1. (MRT Profile Options), is the "Area/Level Border Behavior" specific to multicast?  BTW, please avoid describing the options with questions.

3. Section 1.1. (Importance of 100% Coverage) talks about how micro-loop prevention is something that can be achieved with complete coverage, and Section 12. (Network Convergence and Preparing for the Next Failure) says it is something that needs attention after a failure, but then the document doesn't say how MRT can be used:  the use of MRT (to support Farside Tunneling) is declared out of scope, and an "orphan" statement (no references and no solution) about micro-loop mitigation is made
("Micro-loop mitigation mechanisms can also work when combined with MRT.").
* Section 12.1. (Micro-forwarding loop prevention and MRTs) does say that "Managing micro-loops is an orthogonal issue to having alternates for local repair…", but I think you need to explain some more about how micro-loops may not be an issue or how MRT helps.


4. Section 6.3. (Forwarding IP Unicast Traffic over MRT Paths) says that, for IP forwarding "consistency with LDP is RECOMMENDED".  Why?  I'm guessing it might be simpler to be consistent if both LDP and IP traffic are being repaired, but what about IP-only networks?

5. Section 7.3.1. (Existing IGP exclusion mechanisms)
* "In OSPF…a metric of 2^16-1 (0xFFFF)…"  RFC6987 defined a constant called MaxLinkMetric.
* "…to prevent transit traffic from using a particular router…[RFC6987] specifies setting all outgoing interface metrics to 0xFFFF" -- that won't prevent traffic through the router if it's the only path, look at the R-bit in OSPFv3; for OSPFv2, I think the latest attempt is draft-ietf-ospf-ospfv2-hbit.
* All this doesn't result in an incorrect behavior per the rules at the end of this section.


6. Section 8.3. (Default MRT profile): s/priority/GADAG Root Selection Priority

7. Section 10. (Inter-area Forwarding Behavior)  Are there cases where it is ok (or even desirable) to keep the traffic in MRT-Red/Blue?  The circumstantial case where independent failures occur in different areas sounds like one where the traffic shouldn't be forwarded onto the default topology by the ABR — but this is a case where the ABR is the entry point to a new repair.  Are there others?  I'm just wondering why this Section doesn't commit (s/should/SHOULD or even MUST) to saying that the traffic has to be taken off an MRT at an ABR.

8. Section 12.2. (MRT Recalculation for the Default MRT Profile) includes in the MRT recalculation sequence "a configured (or advertised) period".  Even though this Section talks only about the Default MRT Profile, it seems to me that a "recalculation timer" might be a nice things to have as part of any MRT Profile.
* I peeked at the algorithm ID and didn't find a timer defined there either.




Nits:

1. Please put a reference to Section 7 (?) in 1.2  when talking about MRT Islands.
2. "Any RT is an MRT but many MRTs are not RTs."  Counterintuitive since it sounds like an MRT is the maximal version of an RT.
3. Please expand on first use: SPT, PLR, MT-ID
4. Some substitutions:
* s/it is used to described/it is used to describe
* s/choice of tunnel egress MAY be flexible/choice of tunnel egress is flexible
* s/either IPv4 and IPv6/either IPv4 or IPv6
* s/Forwarding Mechanisms( MRT/Forwarding Mechanisms (MRT
* s/The key difference is whether the traffic, once out of the MRT Island, remains in the same area/level and…/The
key difference is whether the traffic, once out of the MRT Island, remains in the same area/level or…


5. "…we will use the terms area and ABR to indicate either an OSPF area and OSPF ABR or ISIS level and ISIS LBR", but then you use ABR/LBR and area/level anyway.  Suggestion: generalize to domain and DBR, define it in the terminology..
6. Shouldn't there be a reference to Appendix A somewhere in Section 11?