Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)
RFC 7490

Stewart and Mike have been diligent in discussing my concerns and
updating the document (specifically the definitions) to produce a 
version that lets me clear my Discuss. They also picked up some of my
Comments along the way so I have pruned them from this page. There are
still a number of Comments I'd love them to address, but none of these
is blocking.

===

Although it causes some pain with abbreviations and a little more care
in explanation, you need to put the Introduction as the first section in
the document. The RFC editor will insist on this, so it is better if you 
do it now and get the wording exactly how you would like it.

---

You are using RFC 5714 as a Normative Reference by making me go there
for the definition of terms. Please move it to the correct section.

---

IMHO your definition of FIB is rather loose.  Fortunately (?) "FIB" is
barely used in this document, so it might not be important, but if you
wanted to fix it:
- you are talking about IP packets in this document
- the actions are, I think, limited to forwarding actions

---

Throughout the text, the terms P-space, Q-space, and extended P-space
are used rather loosely. For example, when discussing Figure 1 you say
"S's extended P-space", but this is really "S's extended P-space with 
respect to S-E". Someone familiar with the work might say that it is 
obvious from the context that we are discussing the link S-E, and it is,
but the terminology needs to be tight.

---

Section 2

   B
   has equal-cost paths via B-A-S-E and B-C-D-E and so may go through
   S-E.

I don't think B is going anywhere. Maybe...

   B
   has equal-cost paths to E via B-A-S-E and B-C-D-E and so may reach E
   through S-E.

---

Section 2

   In MPLS networks the targeted LDP
   protocol needed to learn the label binding at the repair tunnel
   endpoint is a well understood and widely deployed technology.

But it would still benefit from a citation or a forward reference to
section 7.

---

I enjoyed 3.2

   relatively rare as is the incidence of failure in a well managed
   network.

So, managing my network well is protection against back-hoes. Nice.

---

In 3.2

   Multiple
   repairs MAY share a tunnel end point.

1. s/repairs/repair tunnels/
2. s/MAY/may/ since this is not an implementation or operational choice,
   but a fact of life.

---

In 4.2 you have truncated...

   The repair tunnel endpoint needs to be a node in the network
   reachable from S without traversing S-E.

...and...

   o  The repair tunneled point MUST be reachable from the tunnel source
      without traversing the failed link; and

You mean "reachable using the normal FIB", I think.

---

Section 4.3

   The preceding text has mostly described the computation of the remote
   LFA repair target (PQ) in terms of the intersection of two
   reachability graphs computed using SPFs.

"mostly"?

"reachability graphs"? Were they? Or were they reachability sets?

---

Your pseducode in 4.3 invokes an unresolved (and undescribed) function
Compute_Forward_SPF().

Actually, I think this is a bogus line that can be deleted.

---

I think the introduction of "pseudonode" in 4.3 may be a little without
context.

---

Section 7
   If for any reason the TLDP session cannot
   not be established

s/cannot not/cannot/

---

I think [RFC5424] and [RFC3411] are pretty poor references to give in
section 7. You appear to be saying that an implementation that cannot
establish a TLDP session should write a MIB module, standardise it, and
then report an error.

Can't you find an existing LDP MIB module that reports Session-up
failures?

Or maybe just delete "using any well known mechanism such as Syslog
[RFC5424] or SNMP [RFC3411]."

---

I think you can strengthen the security considerations. You have:

   To prevent their use as an attack vector IP repair tunnel endpoints
   (where used) SHOULD be assigned from a set of addresses that are not
   reachable from outside the routing domain.

1. "To prevent their use" is surely consistent with a "MUST".
   The fact that you want to say "SHOULD" means that you need to turn
   the text around...

   IP repair tunnel endpoints (where used) SHOULD be assigned from a set
   of addresses that are not reachable from outside the routing domain.
   This would prevent their use as an attack vector.

2. You can add a note about what traffic can be placed into a repair
   tunnel. You already have this earlier in the document, and it is
   worth restating.

3. I think you should also make note of whether the repair tunnel is
   advertised by the routing protocol as an available link.