[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] thoughts on the design space 3: caching
- To: "Jari Arkko" <email@example.com>
- Subject: Re: [RRG] thoughts on the design space 3: caching
- From: "William Herrin" <firstname.lastname@example.org>
- Date: Thu, 24 Jul 2008 09:20:38 -0400
- Cc: rrg <email@example.com>
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=n6a+Cx4TO1WH6dgkvvdrWo3+rVH/gdcr/efnPPigX1dUcSVWUrPtHIv+c7diz9QwI6 ZjGiRMflht5U0V24rtCdsa65KN4GbCYWFf+ThvhTQKSqgevL9m4+N0I9fqVEIg+2zrcQ Q37bREFe0qsVwmHhezvTL9Ve6O0YEClDU6KGw=
- In-reply-to: <4888742E.firstname.lastname@example.org>
- References: <4888742E.email@example.com>
On Thu, Jul 24, 2008 at 8:23 AM, Jari Arkko <firstname.lastname@example.org> wrote:
> Second, even if you believe that we DO need a cache, there's really no
> reason why the cache design has to be cast into the rest of the
> architecture. Even if your forwarding ASIC can't employ enough memory for
> all the entries, I have a hard time convincing myself that we can't have a
> general purpose computer sitting next to it that holds the full table. I'm
> writing this on a laptop that has a 160G disk. That would be enough for
> several mapping tables containing EVERY IPV4 ADDRESS.
You make an assumption here: that the ID->Locator map can be made to
remain static over a reasonable period of time. In other words, the
map would only change when someone contracts a new ISP to provide one
of the loctators that reaches them. Ephemeral changes to routing due
to link failures and the like would impact the topology RIB but not
the map. Were this not the case, the amount of static storage would be
irrelevant because you'd have to be able to push updates to the map to
reflect current ID reachability via each registered locator.
Unfortunately, this assumption is trivially demonstrated to be false.
Disconnection between a node and one or more of it's locator-trees
will be a routine event. A local T1 drops. Boom, disconnected. For the
map to remain static, something up the locator tree would need to be
able to -reliably- return a negative acknowledgment to the ITR
indicating that the node is not currently reachable via that locator.
But we already know negative acknowledgments can't be made to generate
and return reliably during an outage event. In any operational system,
we get unexpected routing loops or a firewall blocks the way or a
router malfunctions or the network is congested or something else
happens so that the packet is silently dropped without a NAK.
That's why we detect outages through the absence of positive
William D. Herrin ................ email@example.com firstname.lastname@example.org
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
to unsubscribe send a message to email@example.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg