|
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.” Question: 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 |