|
Hi Linda, Thanks for your question. Please find inline answers. Brgds From: Linda Dunbar [mailto:linda.dunbar@xxxxxxxxxx]
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?
[SLI] D is downstream to the failure, so its path to G is not changed by the C-E link failure. Does D need to delay its forwarding entry to G? [SLI] D is not local to the failure so it does not introduce any delay. 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?
[SLI] D does not delay here. On C we may theoretically have three cases when the convergence occurs for the C-E link failure: -
1) Path is not changed (this is the case of destination D,A,G) -
2) Path is changed and new path may loop (destination E, F) -
3) Path is changed and new path does not loop (destination B). The current text does not make any difference between those cases. For case 1), delaying the FIB update is not an issue as there is already a working FIB entry. Moreover smart implementations may even not update
the FIB at all for those entries. For case 3), we absolutely need to delay to prevent the loop. For case 2), delaying may theoretically add traffic loss. But we mention, that is preferable to use the mechanism coupled with FRR. So when using FRR, the delay
does not introduce any additional impact as the destination uses the FRR path in the meantime. We could have add a logic to detect that a destination may loop or not and apply the delay to only the looping destinations but we thought that the value added was
small when FRR is implemented. Does it mean that C & D have to delay its forwarding entry based on destinations? [SLI] In the current text no. Thank you very much. Linda Dunbar _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. |