A Framework for Loop-Free Convergence
Note: This ballot was opened for revision 07 and is now closed.
(Ross Callon) Yes
(Adrian Farrel) Yes
Comment (2009-10-08 for -)
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 -)
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.