r2r nhrp and destination prefix length extension

Rajesh Varadarajan <rvaradar@fore.com> Sun, 05 May 1996 18:21 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15416; 5 May 96 14:21 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa15412; 5 May 96 14:21 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 OAA23738; Sun, 5 May 1996 14:12:45 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id NAA17556 for rolc-out; Sun, 5 May 1996 13:59:05 -0400 (EDT)
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id NAA17547 for <rolc@nexen.com>; Sun, 5 May 1996 13:59:01 -0400 (EDT)
Received: from fore.com (mailhub.fore.com [192.88.243.4]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id NAA23719 for <rolc@nexen.com>; Sun, 5 May 1996 13:58:59 -0400 (EDT)
Received: from dolphin.fore.com ([192.88.243.27]) by fore.com (8.7.3/8.6.11) with ESMTP id NAA01295 for <rolc@nexen.com>; Sun, 5 May 1996 13:55:48 -0400 (EDT)
Received: from dcdolphin.dc.fore.com ([198.29.27.59]) by dolphin.fore.com (8.7.3/3.4W4) with ESMTP id NAA07815 for <rolc@nexen.com>; Sun, 5 May 1996 13:58:56 -0400 (EDT)
Message-Id: <199605051758.NAA07815@dolphin.fore.com>
To: rolc@nexen.com
Subject: r2r nhrp and destination prefix length extension
Date: Sun, 05 May 1996 14:03:07 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Rajesh Varadarajan <rvaradar@fore.com>
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/

	The r2r nhrp document assumes that the destination prefix length in
a NHRP request could be other than 0xffffffff. However, the NHRP draft explicitly
states that the destination prefix length has to be 0xffffffff in a NHRP request.

	It would therefore clarify things if the r2r nhrp document (or the NHRP draft)
explictly redefine the semantics of the destination prefix extension to allow 
NHRP requests to have the destination prefix extension field have a value other
that 0xffffffff.

Thanks,
rajesh
rajv@fore.com