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.)
<?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office"
/>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.

Unfortunately computing X not-via P (i.e. ANY router not-via and other
router), is MUCH more complex, since it would not only require more
computation, but crucially a lot more addresses.

However, it is possible to perform an operation analogous to PHP
(Penultimate Hop Popping in MPLS). This can be performed at any router
which is in "Q-space" (or G-space as I think it became known)
(see the above draft). i.e once a router determines that its next hop to
Bp is the same as its next hop to B it is free to remove the
encapsulation. This can occur not only at the penultimate hop, but at any
router in Q space of B with respect to the failure. This would permit
traffic which would otherwise "backtrack" to be delivered
directly. However, the concept has not been explored in detail. It is
thought that it would not be suitable for multicast traffic, since the
information about the supposed input interface would be lost
etc.

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.