Comment on draft-bryant-shand-ipfrr-notvia-addresses-03.txt as an rtgwg

from
[Sucec, John M]

Subject:

Comment on draft-bryant-shand-ipfrr-notvia-addresses-03.txt as an rtgwg WG document

From:

"Sucec, John M"

Date:

Fri, 17 Nov 2006 22:42:20 -0500

I have one comment on the IP Fast Reroute Using Not-via Addresses
<draft-bryant-shand-ipfrr-notvia-addresses-03.txt> Internet Draft.(Note: I am relatively new to the RTG WG
so I may have missed previous discussions by the WG on this topic.)

The purpose of this comment is to learn whether optimizations to the
not-via route repair mechanism have been considered to avoid
backtracking.

Quoting from the <draft-bryant-shand-ipfrr-notvia-addresses-03.txt>
Internet Draft:

Page 3 (Section 2): "To repair a failure, the repairing router
encapulates the packet to the not-via address on the far side of the
failure."

And on page 4 (Section 2): "Note that if the path from B to the final
destination includes one or more nodes that are included in the repair path, a
packet may back track after the encapsulation is removed."

Clearly, in the cases of backtracking, it may be more efficient to
instead perform route repair to one of the nodes on the path from B to the final
destination (i.e., use an X not-via P encapsulation instead of B not-via P
encapsulation, where X is on the path from B to the final destination).The tradeoff here is that such an
optimization might increase the computation complexity of the route repair
algorithm running at a node initiating not-via route repair.

In some network scenarios (e.g., for networks with large-delay satellite
links or with small-capacity links) the improved efficiency associated with a
route repair mechanism that avoids backtracking might justify the additional
complexity.In other scenarios, it
may not.

Has any trade study regarding optimizations to avoid backtracking been
considered already by the WG?

Last, regardless of the trade study status, I think this Internet Draft
should be adopted by the WG.