Last Call Review of draft-ietf-rtgwg-uloop-delay-08

Request Review of draft-ietf-rtgwg-uloop-delay
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-10-04
Requested 2017-09-20
Authors Stephane Litkowski, Bruno Decraene, Clarence Filsfils, Pierre Francois
Draft last updated 2017-10-15
Completed reviews Rtgdir Early review of -01 by Matthew Bocci (diff)
Secdir Last Call review of -06 by Melinda Shore (diff)
Genart Last Call review of -06 by Roni Even (diff)
Opsdir Last Call review of -08 by Linda Dunbar (diff)
Assignment Reviewer Linda Dunbar 
State Completed
Review review-ietf-rtgwg-uloop-delay-08-opsdir-lc-dunbar-2017-10-15
Reviewed rev. 08 (document currently at 09)
Review result Has Nits
Review completed: 2017-10-15


I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the operational area directors.
Document editors and WG chairs should treat these comments just like any other last call comments.

Document: draft-ietf-rtgwg-uloop-delay-08

Reviewer: Linda Dunbar

Review result: Have Questions.

Section 6.1 gives an example of when to use the scheme of the proposed delay: Traffic from G to F:  G->D->C->E->F. Your document states: When link C-E fails, if C updates its forwarding entry for F before D, a transient loop occurs.  Therefore, "For traffic from G to F, C delaying the update of its forwarding entry to F."


For reverse traffic, i.e. from F to G, the primary path is F->E->C->D->G
Does it mean that if D updates its forward entry for G before C, a transient loop occurs? Does D need to delay its forwarding entry to G?   i.e. C delaying update of its forwarding entry to F, but D delaying update of its forwarding entry to G. How about to other destinations?

Does it mean that C & D have to delay its forwarding entry based on destinations?

Thank you very much.

Linda Dunbar