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

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

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