latest NHRP I-D

gardo@vnet.ibm.com Mon, 27 November 1995 20:12 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26117; 27 Nov 95 15:12 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa26112; 27 Nov 95 15:12 EST
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.98.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id OAA10502; Mon, 27 Nov 1995 14:41:53 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id OAA01059 for rolc-out; Mon, 27 Nov 1995 14:54:20 -0500
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 OAA01050; Mon, 27 Nov 1995 14:54:17 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: gardo@vnet.ibm.com
Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by guelah.nexen.com (8.6.12/8.6.12) with SMTP id OAA10494; Mon, 27 Nov 1995 14:40:00 -0500
Message-Id: <199511271940.OAA10494@guelah.nexen.com>
Received: from RALVM29 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9934; Mon, 27 Nov 95 14:50:02 EST
Date: Mon, 27 Nov 95 14:21:11 EST
To: luciani@nexen.com
cc: rolc@nexen.com, yakov@cisco.com, genecox@vnet.ibm.com
Subject: latest NHRP I-D
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/
Ref: Your note of Mon, 27 Nov 1995 13:02:55 -0500

Jim,
Welcome back!

>>>Folks,
>>>
>>>Can a Purge message carry optional extensions, and specifically the
>>>Destination Mask extension ? If not, then how one could purge a shortcut
>>>to an address prefix ?
>>>
>>>Yakov.

I was responding to Yakov's question (see above) because I think this
is a real problem in the latest NHRP.

>I did not hear a consensus on this issue!  On the other hand, I am
>happy with the comments that I made.
[...]
>get true consensus before committing things to a draft.

So, you do not agree to include the ability to send a mask in a Purge
because there is no consensus?
I think the mask needs to be included in the draft, as you originally
proposed (see below), because there was a consensus that we need a
mask.

>>James Luciani wrote:
>>>To: shur@arch4.ho.att.com
>>>Subject: Re: Purge packet
>>>In-reply-to: Your message of "Mon, 16 Oct 1995 09:23:41 EDT."
>>>             <9510161323.AA18375@dahlia.ho.att.com>
>>>cc: rolc@nexen.com
>>>Date: Wed, 18 Oct 1995 16:24:56 -0400
>>>From: James Luciani <luciani@nexen.com>
>>>Sender: owner-rolc@nexen.com
>>>[...]
>>>Also, the Destination Prefix Extension as of V4 (and alpha v5) can
>>>only be in the request and reply packets, (read it closely :-( ), so
>>>we need to change that if we go down this path.  Also, we do not want
>>>the prefix as part of the purge packet per se because we want to move
>>>toward a multiprotocol internetworking layer version of NHRP (i.e.,
>>>NHRP for MPON (my new acronym for Multi-Protocol Over NBMA :-) )) and
>>>the internetworking protocol layer address length will be different
>>>from protocol to protocol which argues for a varying length field.  We
>>>also probably don't want to complicate minimum functionality clients
>>>and servers (you'll note that the prefix extension is a
>>>"discretionary" extention) so having the prefix as part of the packet
>>>per se is less desirable.
>>>
>>>An example of new text for the extension follows:
>>>
>>>5.7.1  Destination Prefix Extension (IPv4-Specific)
>>>
>>>  Discretionary = 1
>>>  Type = 1
>>>  Length = 1
>>>
>>>  This extension is used to indicate that the information carried in an
>>>  NHRP Reply/Purge pertains to an equivalence class of internetwork layer destination
>>>  addresses rather than just the internetwork layer destination address
>>>  specified in the request.
>>>
>>>etc...
>>>
>>>
>>>Regards,
>>>-- Jim Luciani
>>>

-- Russell