Re: Final rolc minutes

Joel Halpern <jhalpern@us.newbridge.com> Mon, 29 April 1996 19:22 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16955; 29 Apr 96 15:22 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa16951; 29 Apr 96 15:22 EDT
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id PAA23422; Mon, 29 Apr 1996 15:13:41 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id PAA22639 for rolc-out; Mon, 29 Apr 1996 15:02:30 -0400 (EDT)
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id PAA22630 for <rolc@nexen.com>; Mon, 29 Apr 1996 15:02:26 -0400 (EDT)
Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by nexen.nexen.com (8.7.3/8.7.3) with SMTP id PAA10412 for <rolc@nexen.com>; Mon, 29 Apr 1996 15:02:24 -0400 (EDT)
Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id PAA00796 for <rolc@nexen.com>; Mon, 29 Apr 1996 15:02:23 -0400
Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma000722; Mon Apr 29 15:01:59 1996
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 PAA11818 for <rolc@nexen.com>; Mon, 29 Apr 1996 15:01:52 -0400
Received: from lobster.newbridge by mako.us.Newbridge.com (4.1/SMI-4.0) id AA00820; Mon, 29 Apr 96 14:51:54 EDT
Received: by lobster.newbridge (5.0/SMI-SVR4) id AA08730; Mon, 29 Apr 1996 14:59:40 +0500
Date: Mon, 29 Apr 1996 14:59:40 +0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Joel Halpern <jhalpern@us.newbridge.com>
Message-Id: <9604291859.AA08730@lobster.newbridge>
To: rolc@nexen.com
Subject: Re: Final rolc minutes
X-Sun-Charset: US-ASCII
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: [Un]Subscribe to rolc-request@nexen.com, submissions to rolc@nexen.com
X-Info: Email archive at ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/
X-Info: Hypermail archive at http://cell-relay.indiana.edu/mail/archives/rolc/
X-Info: FTP archive at ftp://ftp.nexen.com/pub/rolc/

I was just re-reading the NHRP draft, and thinking about some routing issues.
I am concerned about the use of the Source NBMA and Source Protocol Address
fields in the request.

Two cases come to mind:
1) The routing protocol is BGP.  The outward path does not have a policy
   restriction on shortcuts, but the assymettric reverse path does.  
   (Someone is being very "careful" about what paths they advertise.)  As 
   currently defined, the destination can learn the sources ATM address,
   and attempt to establish the VC to him anyway, avoiding the fact that 
   an NHRP request in the reverse direction would hit a policy terminator
   who would respond with his own address.
2) The station issuing the query is doing so on behalf of a bridge-like
   device which is the actual ingress to the ATM.  (Yes, there is some
   clever layering here.  Come to MPOA for fun and confusion.)  As such,
   the internetwork source address is the routing entity issuing the 
   query request.  However, in order to cause VCs to match up properly,
   the ATM level source address is that of the bridge-like device which
   will make use of this information.  Therefore,
   A) caching this pairing will not produce good information
   B) sending the response over an existing short-cut will be problematic.

Comments?
Thank you,
Joel M. Halpern				jhalpern@newbridge.com
Newbridge Networks Inc.