Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks
RFC 6571

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

(Stewart Bryant) Yes

(Adrian Farrel) (was Discuss) Yes

Comment (2012-01-02)
No email
send info
Please show "(LFA)" as the acronym for "LoopFree Alternate" at the top
of the Introduction.

---
                                                     
Section 1 could really use a reference to RFC 5714 to establish what LFA
actually means. I would suggest a new five-line paragraph summarising
LFAs.

---

Section 2 starts with...

   In this document, we assume that all links to be protected are point-
   to-point.

The introduction has not mentioned the need to protect any links (nor
what the concept of a protected link is).

---

ISIS and OSPF should have references in Section 2.

(Jari Arkko) No Objection

Comment (2012-01-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Nice doc!

(Ron Bonica) No Objection

(Wesley Eddy) No Objection

Comment (2012-01-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
In Section 3.8, under "Intra Area Destinations", the Node Protection evaluations use "Full" rather than "yes", which is inconsistent with the explanation of terms at the beginning of the section and with the terms used for the next subsection for "Inter Area Destinations".

(Stephen Farrell) No Objection

(Russ Housley) No Objection

Comment (2012-01-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  The Security Considerations say: " This document does not introduce
  any new security considerations."  I am sure this is true, but it
  does not really help the reader.  Please add a sentence pointing the
  reader to security considerations from IP/MPLS.

  The late Gen-ART Review by Suresh Krishnan on 4-Jan-2012 includes a
  good suggestion.  Suresh suggests:

  This draft needs an informative reference to RFC5286. Without this
  reference it is very difficult to get the context required to
  understand this draft. Please consider adding the reference.

(Pete Resnick) No Objection

Comment (2012-01-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I agree wholeheartedly with Peter's comments.

(Dan Romascanu) No Objection

Comment (2012-01-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I would normally enter a DISCUSS on these two issues if the document was standards track. As it is informational I will just mention the issues, in the hope that the authors would agree to consider them before publication. 

1. The document is very dense and not easy reading, and one of the reasons is the lack of context explanation. The reader familiarity with the types of networks and the algorithms is assumed. Even the term Service Provider needs an explanation, there are many kinds of SPs and SP networks. Other example - you need to read through section 4 until you encounter for the first time the term MPLS. 

2. There is very little information on the operational impact of deploying and activating LFAs. Section 6 only makes some claims of reduced complexity without much substantiation. There are no manageability considerations at all. If these are desscribed in another document please specify where. 

(Peter Saint-Andre) No Objection

Comment (2012-01-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Personally I found this document to be nearly impenetrable, but that's probably because the air is so thin up here at the application layer. :) I am balloting "No Objection" on the assumption that our Routing ADs have performed up to their usual high standard of excellence.

(Robert Sparks) No Objection

(Sean Turner) No Objection