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

[Marshall Eubanks <[e-mail]>]

Dear Iljitsch;

On May 8, 2007, at 12:52 PM, Iljitsch van Beijnum wrote:

> 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. 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.
>

Of course, with RP's come the issue of RP discovery - how do I know  
where the RPs are in your /8 ? In IPv6 multicast, the so-called  
embedded RP concept (RFC 3956) has worked fairly well, where the  
address of the RP is embedded directly in the multicast addresses.  
Unless DNS is going to do, I think that something like this should  
IMO be built into any future RP schemes.

Regards
Marshall

> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ram


_______________________________________________
RAM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram