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

"Sucec, John M" <sucecj@telcordia.com> Sat, 18 November 2006 03:42 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlH64-0003OQ-3E; Fri, 17 Nov 2006 22:42:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlH60-0003OG-BJ for rtgwg@ietf.org; Fri, 17 Nov 2006 22:42:24 -0500
Received: from dnsmx2pya.telcordia.com ([128.96.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlH5y-0007pc-Ul for rtgwg@ietf.org; Fri, 17 Nov 2006 22:42:24 -0500
Received: from rrc-dte-ieg01.cc.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx2pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id kAI3gCA01591 for <rtgwg@ietf.org>; Fri, 17 Nov 2006 22:42:12 -0500 (EST)
Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006111722422004182 for <rtgwg@ietf.org>; Fri, 17 Nov 2006 22:42:20 -0500
Received: from rrc-dte-exs03.dte.telcordia.com ([128.96.150.37]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 17 Nov 2006 22:42:20 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 17 Nov 2006 22:42:20 -0500
Message-ID: <47645576F4132445A62FC016820E82E7059DF139@rrc-dte-exs03.dte.telcordia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comment on draft-bryant-shand-ipfrr-notvia-addresses-03.txt as an rtgwg WG document
Thread-Index: AccCg/MTN/+ZkVatR+CNhJ0OY7gvdgIPphAB
From: "Sucec, John M" <sucecj@telcordia.com>
To: rtgwg@ietf.org
X-OriginalArrivalTime: 18 Nov 2006 03:42:20.0466 (UTC) FILETIME=[8D0C9120:01C70AC3]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f2984bf50fb52a9e56055f779793d783
Subject: Comment on draft-bryant-shand-ipfrr-notvia-addresses-03.txt as an rtgwg WG document
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: rtgwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1316752688=="
Errors-To: rtgwg-bounces@ietf.org

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
rtgwg@ietf.org
https://www1.ietf.org/mailman/listinfo/rtgwg