[email protected]
[Top] [All Lists]

Re: [RRG] Re: FYI -- Informal LISP BOF scheduled for lunch time on Thurs

Subject: Re: [RRG] Re: FYI -- Informal LISP BOF scheduled for lunch time on Thursday
From: "Greg Shepherd"
Date: Thu, 6 Dec 2007 09:33:35 -0800
On Dec 6, 2007 8:02 AM, Robert Raszuk <[email protected]> wrote:
> Noel,
> > The issue is not just how many routes any box (or set of them) can hold
> > (although that is a significant concern, because there is installed base all
> > over the world, and not all the component organizations have budget to
> > replace/upgrade it all freely).
> I am not suggesting massive worldwide upgrade :) I am convinced that
> currently deployed routers in the Internet core would do just fine with
> the help of just control plane changes. Contrary currently proposed
> schemes do require hardware changes/additions for interdomain tunneling.
> > The thing is that today's routing architecture is a giant distributed
> > computation, one which doesn't 'run to completion', but is always running,
> > responding to changes in the world-wide physical connectivity. A change
> > happens, and things respond, and eventually affected paths settle down and
> > stabilize after some time Ts.
> That is true and the possible upcoming impact of knee effect of IPv4
> addresses should not be dismissed. But my observation lead me to believe
>   that various proposals here are building a Titanic solutions where
> what is needed to be on the safer side is just a new operational mode to
> the current boat.
> In particular to increase overall system stability and Internet safety
> margin I would recommend to consider a very simple approach ...
> To separate in current today's BGP prefixes from next hop. To converge
> next hops aggressively while increasing the timers for prefixes. Very
> simple and IMHO quite effective way to reduce the product of "# of
> prefixes * change rate".
> And such separation could be just new SAFI for next hops. Easy to
> gradually deploy, does not require new mapping layers, can be user with
> intra or inter domain tunneling (but this is not a must) ....

Good point(s). And work like this should continue independent of
whether others are working on new architecture approaches. The
discussion about whether or not there is a larger problem that needs
solving will never come to a conclusion until/unless the problem
reveals itself in some unfortunate way.

> To summarize I am not convinced .. why we are jumping into the ocean
> while there is plenty of room in the current pool to swim.

But wouldn't it be great if when you finally find yourself with no
more room in the pool, to find someone has already prepared the way
for you to make your move over to the ocean?


> Cheers,
> R.
> _______________________________________________
> rtgwg mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rtgwg

rtgwg mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>