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

Note: This ballot was opened for revision 09 and is now closed.

(Alia Atlas) Yes

(Adrian Farrel) (was Discuss) Yes

Comment (2015-01-06 for -10)
No email
send info
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.

(Jari Arkko) No Objection

Comment (2015-01-07 for -10)
No email
send info
Suresh Krishnan made two points in his Gen-ART review that should probably be taken into account.

(Richard Barnes) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2015-01-07 for -10)
No email
send info
- 3.2 1st para: I'm sure that IPsec would have
downsides (possibly fatal) as a tunneling mechanism,
but OTOH, it might also have some benefits if the
endpoints are in the same domain but not all
non-endpoints traversed by the tunnel are.  That's
probably too much of a change to include unless you
really wanted to, but I thought I'd just ask in case.

- 4.3 - this is probably insignificant but is there a
potential DoS if I can try force a node to run this (or
an equivalent) algorithm frequently? 

- I agree with Adrian's points about the security
considerations. One question on that (I only skimmed
this, sorry) - Adrian said: "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." Which text is that? Is there a
requirement somewhere that the new tunnel described
here SHOULD have the same security properties as the
link(s) for which it's a backup?

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2015-01-05 for -09)
No email
send info
The title should be changed to "Remote Loop-Free Alternate (LFA) Fast Re-Route (FRR)", but it's not critical to do that now: the RFC Editor will do it if you don't.

Otherwise: I found this to be an easy and understandable read. Thanks.

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-01-06 for -10)
No email
send info
Thanks for your work on this draft.

I support Adrian's comments on additions/changes for the security considerations section and would like to see them added.

Additionally, Adrian raised the point of having the introduction first.  As someone outside of routing, I think this would make the draft easier to read.  

The terminology section should state that it is using figure 1 in each of the definitions.  When the order is changed so this section follows the introduction, that may be more clear, but a statement to that effect would be helpful IMO.

(Pete Resnick) No Objection

Comment (2015-01-07 for -10)
No email
send info
Throughout the doc there is a word we see.
The queen would be so proud of what we write.
For we are so amused by this strange use,
it is some sixteen times "we" does appear.
Perhaps we'd like the passive voice instead.

(Martin Stiemerling) No Objection