[email protected]
[Top] [All Lists]

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

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.


rtgwg mailing list
[email protected]
<Prev in Thread] Current Thread [Next in Thread>