On Thu, Jul 24, 2008 at 9:50 AM, Jari Arkko <[EMAIL PROTECTED]> 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 ................ [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 -- to unsubscribe send a message to [EMAIL PROTECTED] 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
