Re: A tunneling proposal

[RJ Atkinson <rja@inet.org>]

At 05:21 17/07/01, Iljitsch van Beijnum wrote:
>> The veracity of "Routers run just fine with 100,000 routes..." 
>> depends on how you define "fine".
>
>A few weeks ago, someone posted a survey on the list. Nobody answered "we
>can't handle the huge number or routers" on it.

NOTE:
        Probability of a given person answering a survey on the NANOG list 
is inversely proportional to the probability that the person works
for a major IP carrier and has at least one clue about routing.

>> Modern routers don't fall over with 100,000 routes in them. 
>> But initial table load and BGP convergence times when paths change 
>> are both a lot longer than many would like.
>
>Ok, but is that enough reason to throw out the current way of multihoming?

        Yes.

>>> On top of that, each route takes a LOT of memory: 240 bytes 
>>> for the routing table and for each peer route in the BGP table 
>>> in a Cisco.
>
>> The size of individual routing state entries in modern routers 
>> has been the subject of a great deal of optimization over the years. 
>> Don't expect to see it improved by an order of magnitude or even 
>> by a factor of two. 
>
>Really? 

        Yes.

>> Memory size is not the principal issue; memory speed and 
>> routing table update bandwidth are.
>
>You have a point on the table updates. A solution for that could be to only
>allow information about routes going down to be immediately forwarded, since
>this is presumably an operation that can be optimized not to be very
>expensive. New route announcements could be slowed down.

Immediately forwarding information about routes going down
increases the load on the overall routing system due to route flaps.

Dealing with this system loading issue caused by route flaps
is precisely why BGP has dampening.

>I don't believe memory speed is a reason to keep the routing table at its
>current size: doing a binary search on 10,000,000 rather than 100,000 items
>only takes 24 steps rather than 17. If this is a problem for 10,000,000
>routes, 100,000 routes is too much as well.

Some think that 100K prefixes is already uncomfortably large 
for the algorithms currently being used.  Others think that
that the critical point is more nearly 200K prefixes.  Folks
mileage varies somewhat on where the critical point lies
with the current algorithms.  Note my phrasing.  I talk about
"algorithms" rather than "implementations" quite deliberately.

>Do we have any inidication that the global routing table is 
>growing faster than the Moore's Law rate?

As I recall, tli has made precisely this claim in the past.  
I'm strongly inclined to just take tli's word on such a point.

>> Eliminating CIDR will guarentee hyper-exponential growth - for all
>> the talk about how CIDR has "failed" in that growth is continuing, 
>> the growth rate would be far, far worse without it - aggregation 
>> has successfully "hidden" at least an order of magnitude of growth.
>
>I'm not saying "CIDR is dead, everybody stop aggregating". But CIDR has
>reached the limits of its capabilities. Just look at the routing table 
>vs the number of AS numbers: for every assigned ASN there are five routes.

However, a typical AS is not originating 5 routes.  One needs to be
fairly careful in playing with statistics in this space.

>> Look back at old archives of the IETF and other lists to read some of Noel
>> Chiappa's and others' writings on the mathematics of network topology and
>> addressing. If the "addresses" used by routing don't follow the underlying
>> network topology, excessive state is introduced. For multihoming to really
>> work, it needs to use topologically-significant addressing. That suggests
>> that the "multi" in "multihoming" also implies multiple addresses, with
>> something like SCTP to handle them intelligently.
>
>1. Forget SCTP: if we want this, we should build it into TCP and not change
>   transport layers to a protocol that has just one desirable feature and
>   forget 20 years of experience with the most successful protocol in
>   history.

In the past, this sort of change to TCP was precisely forbidden
procedurally.  I agree the community should seriously examine ways
in which the clues from SCTP multihoming might be injected into
the UDP and TCP protocols.  I don't understand if examining such
changes would be within scope for this WG or would belong elsewhere.

>2. The current way of multihoming works much better for the multihomed
>   network, what is their incentive to go with multiple addresses?

Economics is a major constraint on the potential solution space.

Ran
rja@inet.org