A Framework for Loop-Free Convergence
RFC 5715

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

(Ross Callon) Yes

(Adrian Farrel) Yes

Comment (2009-10-08 for -)
No email
send info
Section 3 has

   Throughout this document we use the term SRLG to describe
   the procedure to be followed when multiple failures have occurred
   whether or not they are members of an explicit SRLG.

s/to describe/when describing/

---

Echo the point on the the ToS byte.
Suggest to completely remove the sentence.

---

I think it is unfortunate that section 12 is so skinny. I presume that
if I am able to induce micro loops (perhaps by flapping a resource) I
could cause considerable network disruption and so using loop prevention
or mitigation is a protection.

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ralph Droms) No Objection

(Lars Eggert) No Objection

Comment (2009-10-07 for -)
No email
send info
Very nice document overall!

Section 6.5., paragraph 5:
>    This
>    could, for example, be achieved by allocating a Type of Service bit
>    to the task[RFC0791].  This mechanism works identically for both
>    "bad-news" and "good-news" events.  It also works identically for
>    SRLG failure.  There are three problems with this solution:

  There is no "ToS byte" anymore since DiffServ was published. Using a
  DSCP for that purpose is also not really in tune with the DiffServ
  architecture. Suggest to remove this example or point out in the list
  following this paragraph that that's also a drawback.

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Tim Polk) No Objection

(Robert Sparks) No Objection