RE: [RAM] The mapping problem: rendezvous points?

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]
> Sent: Tuesday, May 08, 2007 9:53 AM
> To: ram@iab.org
> Subject: [RAM] The mapping problem: rendezvous points?
> 
> We basically have two choices for the mapping mechanism: work on-
> demand and cache the result for some time, or flood everything ahead
> of time. 

I disagree with the word "everything".  The two high level choices are:

PULL: work on-demand (which results in deterministic loss and hence
adversely affects applications) and cache the result for some time

PUSH: learn enough information (which may or may not be everything)
ahead of time so that one has enough information to immediately forward
a packet when it arrives.  It would be desirable to learn log(N)
information (and everyone may not learn the same information).

Flooding everything is a type of PUSH, and has scalability issues.
DHTs distributing log(N) information to each node are another type of
PUSH, and don't have the scalability issues.

Rendezvous points as you suggest below are another type of PUSH, where
the non-rendezvous points have a small amount of information, but if I
understand you correctly, the RPs still have the same scalability issues
as flooding everything.

-Dave

> Both approaches are problematic: caches are vulnerable to
> sudden changes in the mix of destinations in the traffic, and there
> is a delay between the moment routing information is needed and the
> moment it becomes available. Then again, BGP shows that flooding
> everything everywhere isn't so great when you can't control the size
> or volatility of the underlying data.
> 
> An analogy in the real world: large stores carry very many items by
> way of many distributors. Rather than have every store maintain a
> direct relationship with every vendor and suffer a huge information
> explosion on both ends, there is stuff in the middle that handles
> distribution so each vendor and each store only deals with a limited
> number of other organizations.
> 
> Something like that may be useful in our problem space, too. The way
> I imagine this is by having rendezvous points where the reachability
> information for subsets of the network comes together. For instance,
> as a large ISP, I could have a small number of routers handle a
> certain /8 out of IPv4 space. All the other routers route their
> traffic for this prefix to the closest one of the rendezvous routers
> in question. These then forward the traffic as per more specific
> routing information if possible, or encapsulate it if necessary.
> 
> The rendezvous point is where traffic and routing information all
> come together.
> 
> Compared to an on-demand model, this has the advantage that there are
> no delays and no caching issues. Compared to a flooding model, it has
> the advantage that the full specific information is only required in
> relatively few places. This can work with both a very small number of
> very large routers, or a much larger number of much smaller routers,
> as long as the aggregate capacity in routing table size and bandwidth
> is adequate.
> 
> The downside is that not having the same information available
> throughout an AS increases operational and/or protocol complexity.
> 
> _______________________________________________
> RAM mailing list
> RAM@iab.org
> https://www1.ietf.org/mailman/listinfo/ram

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram