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.
- Final ROLC minutes from Stockholm Andy Malis
- Re: Final ROLC minutes from Stockholm shur
- Re: Final ROLC minutes from Stockholm Andrew G. Malis
- Re: Final ROLC minutes from Stockholm shur