Re: NHS Record extensions seem to be unnecessary

Joel Halpern <jhalpern@newbridge.com> Thu, 24 August 1995 13:41 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10933; 24 Aug 95 9:41 EDT
Received: from nexen.nexen.com by IETF.CNRI.Reston.VA.US id aa10929; 24 Aug 95 9:41 EDT
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id JAA03748; Thu, 24 Aug 1995 09:27:07 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id JAA29067 for rolc-out; Thu, 24 Aug 1995 09:22:29 -0400
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id JAA29058 for <rolc@nexen.com>; Thu, 24 Aug 1995 09:22:26 -0400
Received: from ns.newbridge.com (ns.Newbridge.Com [192.75.23.67]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id JAA28968 for <rolc@nexen.com>; Thu, 24 Aug 1995 09:19:35 -0400
Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id JAA20326 for <rolc@nexen.com>; Thu, 24 Aug 1995 09:20:39 -0400
Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma020319; Thu Aug 24 09:20:20 1995
Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id JAA05918 for <rolc@nexen.com>; Thu, 24 Aug 1995 09:20:16 -0400
Received: from lobster.Newbridge.COM by mako.us.Newbridge.com (4.1/SMI-4.0) id AA23798; Thu, 24 Aug 95 09:17:10 EDT
Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA24960; Thu, 24 Aug 1995 09:19:24 +0500
Date: Thu, 24 Aug 1995 09:19:24 +0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Joel Halpern <jhalpern@newbridge.com>
Message-Id: <9508241319.AA24960@lobster.Newbridge.COM>
To: rolc@nexen.com
Subject: Re: NHS Record extensions seem to be unnecessary
X-Sun-Charset: US-ASCII
Content-Length: 976
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/

When we put in the route recording option, the original motivation had
nothing to do with debugging.  The concern was how to cope with ATM
level policy restrictions.  One could easily imagine restrictions such
that ATM connections could not be established all the way to the
destination, even though it all appeared to be one ATM network. 

It was thought that by providing the forward path the source would be
able to establish the shortcut VC to the furthest possible place.  This
would serve to complement the fact that if the intiating hsot can't get
out (a nearby policy restriction) that a router down the way would
presumably establish a shortcut path after a while.  The two mechnisms
are designed to cope with the two likely policy restriction scenarios.

It was thought that these were significant issues, and I believe that
they appear on our base list describing the problem to be solved.

Yours,
Joel M. Halpern				jhalpern@newbridge.com
Newbridge Networks Inc.