Subject: RE: PI space (was: Stupid NAT tricks and how to stop them)

From: "Michel Py" <[email-masked]>
Date: Thu, 30 Mar 2006 19:57:30 -0800

> Noel Chiappa wrote:
> Needless to say, the real-time taken for this process to complete
> - i.e. for routes to a particular destination to stabilize, after
> a topology change which affects some subset of them - is dominated
> by the speed-of-light transmission delays across the Internet
> fabric. You can make the speed of your processors infinite and it
> won't make much of a difference.

This is total bull. The past stability issues in BGP have little to do
with latency and everything to do with processing power and bandwidth
available to propagate updates. In other words, it does not make any
difference in the real world if you're using a 150ms oceanic cable or a
800ms geosynchronous satlink as long as the pipe is big enough and there
are enough horses under the hood.

Only if we were shooting for a sub-second global BGP convergence the
speed of light would matter.

> Stephen Sprunk wrote:
> The IPv4 core is running around 180k routes today, and even
> the chicken littles aren't complaining the sky is falling.

I was about to make the same point. Ever heard whining about a 7500 with
RSP2s not being able to handle it? Yes. Ever heard about a decently
configured GSR not being able to handle it? No. Heard whining about
receiving a full table over a T1? Yes. Heard whining about receiving a
full table over an OC-48? No.

Anybody still filtering at /20 like everybody did a few years back?

> and the vendors can easily raise those limits if customers demand
> it (though they'd much prefer charging $1000 for $1 worth of RAM
> that's too old to work in a modern PC).

You're slightly exaggerating here. I remember paying $1,900 for 32MB of
ram worth $50 in the street :-D

Michel.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 30 Mar 2006 23:10:57 -0500 (EST)

> From: "Michel Py" <[email-masked]>

    >> - i.e. for routes to a particular destination to stabilize, after a
    >> topology change which affects some subset of them - is dominated by
    >> the speed-of-light transmission delays across the Internet fabric. You
    >> can make the speed of your processors infinite and it wqwon't make
    >> much of a difference.

    > The past stability issues in BGP have little to do with latency and
    > everything to do with processing power and bandwidth available to
    > propagate updates.

The past stability issues had a number of causes, including protocol
implementation issues, IIRC.

In any event, I was speaking of the present/future, not the past. Yes, *in
the past*, processing power and bandwidth limits were an *additional* issue.
However, that was in the past - *now*, the principal term in stabilization
time is propogation delay.

    > In other words, it does not make any difference in the real world if
    > you're using a 150ms oceanic cable or a 800ms geosynchronous satlink as
    > long as the pipe is big enough and there are enough horses under the
    > hood.

If you think there aren't still stability issues, why don't you try getting
rid of all the BGP dampening stuff, then? Have any major ISP's out there done
that?

	Noel