Re: Final ROLC minutes from Stockholm

shur@arch4.ho.att.com Fri, 11 August 1995 14:09 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10665; 11 Aug 95 10:09 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa10660; 11 Aug 95 10:09 EDT
Received: from maelstrom.acton.timeplex.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id JAA15043; Fri, 11 Aug 1995 09:56:28 -0400
Received: (from root@localhost) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) id JAA27758 for rolc-out; Fri, 11 Aug 1995 09:53:27 -0400
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) with ESMTP id JAA27749; Fri, 11 Aug 1995 09:53:24 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: shur@arch4.ho.att.com
Received: from gw2.att.com (gw2.att.com [192.20.239.134]) by guelah.nexen.com (8.6.12/8.6.12) with SMTP id JAA15026; Fri, 11 Aug 1995 09:52:05 -0400
Received: from arch4.ho.att.com by ig1.att.att.com id AA18367; Fri, 11 Aug 95 09:40:10 EDT
Received: from dahlia.ho.att.com by arch4.ho.att.com (4.1/EMS-1.2 GIS) id AA09894; Fri, 11 Aug 95 09:40:35 EDT
Received: by dahlia.ho.att.com (4.1/EMS-1.1 SunOS) id AA00526; Fri, 11 Aug 95 09:40:51 EDT
Date: Fri, 11 Aug 95 09:40:51 EDT
Message-Id: <9508111340.AA00526@dahlia.ho.att.com>
To: malis@nexen.com
Subject: Re: Final ROLC minutes from Stockholm
Cc: rolc@nexen.com
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/

Andy,

> > > From the ROLC minutes
> > > 2. Include destination address in Purge requests - agreed.
> >
> > Could someone clarify - which destination address is this? Is it the
> > target of the original NHRP query?
> 
> Yup.  The issue is that for the Purge message, draft -04 requires the
> use of the Request ID field as the key to search the cache, and this
> is the only use of this field as a search key - all other cache
> lookups are keyed off the destination address in the original NHRP
> query.  To make the Purge consistent with other NHRP messages, and
> only require one cache search key, it will now have the exact same
> syntax as the Request and Reply packets - Request ID, Dest. Addr,
> Source Addr.
> 
> > If so, it might be useful to also allow the network address
> > associated with an off-NBMA target to also be included in Purge
> > requests.
> 
> Could you elucidate?  If by "network address" you mean the destination
> IP or other network layer address, it's already there. 
 
Thanks for the clarification. I meant the IP address. How do you mean its 
already there? If the original query target was an individual host
address off the NBMA, and a routing change occurred such that the orginal
path was no longer valid, I was thinking
the purge should contain at least the IP address info for the subnet
the target is part of. Maybe the purge should contain all off-NBMA
IP network addresses that are no longer reachable. That way a recipient
of a single purge message may be able to delete multiple cache entries
based on a single purge message. This could also
reduce the number of purge messages needing to be sent, as well as reduce
the state information needing to be tracked at NHRP capable routers.

Your text above suggests that the destination
address of the PURGE is the same as that of the original query. What
I am asking about implies the  target address of the query is a subset of
the "destination field" of the purge message.

> If you mean
> the NBMA address, why would you want to include it?  The whole point
> of the message is to cause cache entries to be removed.
> 
> Cheers,
> Andy
> 
Thanks,
david.