Re: [RRG] thoughts on the design space 3: caching

["William Herrin" <bill@herrin.us>]

On Thu, Jul 24, 2008 at 9:50 AM, Jari Arkko <jari.arkko@piuha.net> wrote:
> There are potentially multiple levels of information here. There is the
> global map, be it from NERD or any other global system and it needs to be
> fairly static. E.g., a mapping from an identifier space into the addresses
> of the ITRs. Then there is a separate, more dynamic information which has to
> do with the current preferences and status of those ITRs.

Jari,

You meant to say ETRs, right? The map that indicates which IDs are
reachable from which tunnel Exits?

I could swear I had this out with someone else just a few months ago.
The following scenario illustrates the problem:

Node X declares in the map that he is reachable from both ETRs A and
B. In fact, A and B are physically also routers belonging to two
different ISPs while X is physically a router at a customer site. X is
connected to A via a T1 data circuit labelled AX and to B, via a T1
data circuit labelled BX. Somewhere out there is an origin ITR we'll
call O. A is closer to O than B, so O normally sends packets to X via
A.

Link AX fails. Now what?

Solution #1: When A receives a packet for X from O, A sends a NAK back
to O informing it that X is temporarily unreachable via A. THIS DOES
NOT WORK. The character of the failure may prevent A from realizing
that X isn't reachable. The character of the failure may allow O to
think that X is still reachable via A even though A is malfunctioning
and will silently drop packets for X. The character of the failure may
allow O to think that A is still reachable even though packets to A
are silently dropped. In each case, the operator at X has no recourse
through which he can advise ITRs like O that he is temporarily
unreachable via A.

Solution #2: When A receives a packet for X from O, A reroutes the
packet to B for delivery to O. THIS DOES NOT WORK. Same reasons.

Solution #3: When X realizes that it no longer has a reliable
connection to A, it updates the map to reflect that it is no longer
reachable via A. THIS WORKS.

What's solution #4? What allows an end-node operator to cut out a
temporarily flaky upstream without updating the map?


Let me put it another way: you can't reliably get an automated list of
what -isn't- working right because, guess what, they aren't working
right! What you can reliably get is a list of things that -are-
working right. Can I get a "duh?"

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin@dirtside.com bill@herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to rrg-request@psg.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