[RRG] Re: Not moving the problem to the global mapping system

[Michael Meisel <meisel@cs.ucla.edu>]

Brian E Carpenter wrote:
> On 2008-04-10 17:54, Michael Meisel wrote:
> ...
> > I think we should ask this question in terms of the problems we are
> > trying to solve. As we all know, one of these problems is the frequency
> > of BGP updates today, which are largely coming from edge network. To put
> > it a different way, the problem is that the reachability information for
> > even the smallest of edge networks is announced globally. Each update
> > requires a significant amount of processing by each node that it passes
> > through. So the mapping system better not suffer from this same problem,
> > or we haven't done any good!
> >
> > So, specifically, we should be asking:
> >
> > (1) Is the mapping function successful in preventing edge network
> > reachability from being propagated into the global routing system?
> >
> > (2) If yes, does it do so without simply moving the problem to the
> > global mapping system?
> >
> > Note that proposals that both (a) put reachability information into the
> > mapping system and (b) involve any sort of push model start to look a
> > lot like BGP, and therefore are going to have a hard time answering
> > "yes" to (2) convincingly.
>
> I can't say how much I agree with this. If the mapping system
> degenerates into a reachability-driven routing system, we might
> just as well switch to two layers of BGP immediately.

I think I wasn't clear, because it sounds like we very much agree. I 
think we should expect a "yes" answer to both questions, and a mapping 
system like you describe is exactly the sort that would have trouble 
doing so.

> I would suggest turning this into a concrete goal, such as:
>
> <strawman>
> The update rate in the mapping system should be at least
> two orders of magnitude less than the update rate in
> the BGP4 system, at any point in time.
> </strawman>

Yeah, I think something like that is reasonable, though I think "update 
rate" is probably both too vague and too narrow a metric. We need to 
take into account the order of magnitude in number of devices doing the 
processing, processing required per update, and probably other things I 
haven't thought of.

But I still wonder -- is it truly a useful step towards solving the 
scalability problem to develop a list of such constraints, in and of 
itself? Or is it only useful if we use those constraints to evaluate 
concrete designs? I'm tending towards the latter.

-Michael


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