The Routing Over Large Clouds Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1995-Nov> msg00150



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

latest NHRP I-D

  • From: gardo@vnet.ibm.com
  • Date: Mon, 27 Nov 95 14:21:11 EST
  • cc: rolc@nexen.com, yakov@cisco.com, genecox@vnet.ibm.com
  • Ref: Your note of Mon, 27 Nov 1995 13:02:55 -0500
  • X-Orig-Sender: owner-rolc@nexen.com

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