Michael, we *do* agree, maybe I confused you by not using a double negative ;-)
Brian On 2008-04-11 10:01, Michael Meisel wrote: > 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 [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
