And Now for Something Completely Different (was Re: IPv6 news)

Mon Oct 17 18:29:50 UTC 2005

OK. What you just described is akin to an enterprise network with a  
default route. It's also akin to the way DNS works.

The big question becomes not only "who knows what I need to know",  
but "how do I know that they actually know it?". For example, let's  
postulate that the concept is that each ISP advertises some sort of  
routing service that will install routes on demand, but requires that  
someone initiate a request for the route, and requires either the  
target system or the edge router in that domain that is closest to  
the target respond with a route.

Simplistically, perhaps I am trying to route from my edge network  
("A") towards your edge network ("B"), and we are both customers of  
some ISP ("C"). The host A' that is trying to get to your host B'  
initiates a request. Lets presume that this goes to some name in  
domain A that lists all border routers, or some multicast group that  
they are members of. Presumably every border router does this, but  
for present discussion the border router in A connecting to router C'  
in C asks all of his peers (POPs?) for the route, and some other  
router C" asks B's border router. B's border router has the route,  
and so replies; C" replies to C', C' to A's border router, and that  
router to A'. A' can now send a message.

Presumably, if someone else now ask C about the route, either C' or  
C", or if the route was multicast to all of C's edge routers then any  
router in C would be able to respond directly.

This becomes more interesting if C is in fact a succession of peer  
ISPs or ISPs that purchase transit from other ISPs. It also becomes  
very interesting if some router D' is misconfigured to advertise  
itself as B.

It's not dissimilar to ant routing. For that, there is a variety of  
literature; Google is your friend. In manet and sensor networks, it  
works pretty well, especially in the sense that once it finds a route  
it keeps using it while it continues working even if other routes are  
changing around it, and it can use local repair to deal with local  
changes.

At least as the researchers have described it, it doesn't do "policy"  
very well, and in networks that tend to be stable (such as wired  
networks) its load and convergence properties can be improved on.

I'll let you read there.

On Oct 17, 2005, at 9:20 AM, Per Heldal wrote:

> man, 17,.10.2005 kl. 07.25 -0700, skrev Fred Baker:
>
>> is that anything like using, in Cisco terms, a "fast-switching cache"
>> vs a "FIB"?
>>
>
> I'll bite as I wrote the paragraph you're quoting;
>
> Actually, hanging on to the old concepts may be more confusing than
> trying to look at it in completely new ways.
>
> Imagine a situation with no access to any means of direct  
> communication
> (phone etc). You've got a message to deliver to some person, and  
> have no
> idea where to find that person. Chances are there's a group of people
> nearby you can ask. They may know how to find the one you're looking
> for. If not they may know others they can ask on your behalf. Several
> iterations later the person is located and you've established a path
> through which you can pass the information you wanted.
>
> Translated into cisco terms this mean that the FIB is just a partial
> routing database, enough to start the search and otherwise handle
> communications in the neighborhood (no more than X router-hops, maybe
> AS-hops away). When the destination is located you keep that  
> information
> for a while in case there are more packets going to the same place,
> similar to what you do with traditional route-cache.
>
>
>>
>> On Oct 17, 2005, at 6:47 AM, Mikael Abrahamsson wrote:
>>
>>>> Well, let's try to turn the problem on its head and see if thats
>>>> clearer; Imagine an internet where only your closest neighbors
>>>> know you exist. The rest of the internet knows nothing about you,
>>>> except there are mechanisms that let them "track you down" when
>>>> necessary. That is very different from today's full-routing-table.
>