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.
- Final rolc minutes Andrew G. Malis
- Re: Final rolc minutes Joel Halpern
- Re: Final rolc minutes Andrew Smith
- Re: Final rolc minutes Eric W. Gray
- Re: Final rolc minutes James V. Luciani
- Re: Final rolc minutes Eric W. Gray