recent changes requested on the list
gardo@vnet.ibm.com Thu, 26 October 1995 01:22 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22683;
25 Oct 95 21:22 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa22679;
25 Oct 95 21:22 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com
(8.6.12/8.6.12) with ESMTP id UAA20544; Wed, 25 Oct 1995 20:45:22 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id
UAA02268 for rolc-out; Wed, 25 Oct 1995 20:53:55 -0400
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 UAA02259;
Wed, 25 Oct 1995 20:53:52 -0400
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 UAA20532; Wed, 25 Oct 1995 20:42:32 -0400
Message-Id: <199510260042.UAA20532@guelah.nexen.com>
Received: from RALVM29 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2622;
Wed, 25 Oct 95 20:48:47 EDT
Date: Wed, 25 Oct 95 20:25:34 EDT
To: luciani@nexen.com
cc: rolc@nexen.com, genecox@vnet.ibm.com
Subject: recent changes requested on the list
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: My note of 25 October 1995, 15:34:18 EDT
Ref: Your note of Wed, 25 Oct 1995 14:32:32 -0400
Jim,
>> Things I did not address below are:
>...
>> C) Russel's request to add a destination address mask field to the
>> IP-specific part of the Purge packet.
>...
>>
>>On 'C', I'd prefer to just allow the destination prefix extension to
>>be included in the purge packet (which it currently is not) and
>>I would very much prefer to see this be optional and not a
>>requirement. I do see value in it though.
>
>I prefer that the mask be added to the IP-specific mandatory
>part because it is not imposing any real additional overhead in the
>clients to perform a bit-wise AND with a mask when matching
>the destination address on a purge.
>I have one major concern about your proposal to add an extension
>to the Purge packet. I'm concerned that putting the mask in the
>extension part will limit the flexibility of the purge feature.
>However, ...
I think putting it into an extension would be good if there is a way
for a client to tell the server which packet types it supports for
the extension. It needs to be flexible enough to allow a client to
specify which packet types it supports for the destination prefix
extension. Add two bits in the destination prefix extension that are
used when appending the extension to the Request packet. Here is the
definition of the bits:
R-bit: Client supports extension in Reply packets
P-bit: Client supports extension in Purge packets
What do you think?
-- Russell
- recent changes requested on the list James Luciani
- Re: recent changes requested on the list Bruce Cole
- recent changes requested on the list gardo
- Re: recent changes requested on the list Eric Gray
- Re: recent changes requested on the list James Luciani
- ACK of register and purge packets Bruce Cole