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

[mike shand <[e-mail]>]

At 03:42 18/11/2006, Sucec, John M wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary="----_=_NextPart_001_01C70AC3.8CFAAD40"

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.

They have been thought about, but dismissed as overcomplex.

An earlier approach to the problem, (described in the now expired draft http://www.watersprings.org/pub/id/draft-bryant-ipfrr-tunnels-02.txt" rel="nofollow"> http://www.watersprings.org/pub/id/draft-bryant-ipfrr-tunnels-02.txt) did tunnel to the nearest router which guaranteed correct delivery, but this turned out to have complex corner cases.

 

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.

 
John
 
_______________________________________________
rtgwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rtgwg" rel="nofollow"> https://www1.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
rtgwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rtgwg