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

From: "Sucec, John M" <[email-masked]>
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.

John
 
_______________________________________________
rtgwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg

---

From: mike shand <[email-masked]>
Date: Mon, 20 Nov 2006 10:06:03 +0000

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)
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

[email-masked]