Filtering prefixes longer than /24

[Robert J. Rockell]

I know of networks other than my own that are running over 200,000 routes
currently (granted, probably not optimal).

The table size is not onlyk a memory issue, but a forwarding ASIC issue that
needs consideration.  I would argue (and here comes a giant thread) that a
TCP enhancement/re-write with renumbering may provide the scale people want,
without putting the burden on the mtrie.

Thanks
Rob Rockell
Principal Engineer
SprintLink Europe/Asia
703-689-6322
Sprint E|Solutions: Thinking outside the 435 box
-----------------------------------------------------------------------

On Mon, 9 Jul 2001, Pekka Savola wrote:

->On Mon, 9 Jul 2001, Robert J. Rockell wrote:
->> If this makes multi-homing difficult, or the like; that is sort of the
->> point. This is all supposed to be aggregatable at the most fundamental
->> levels, thus putting a top limit on the number of non-customer routes a TLA
->> will have to carry. Violating this just adds factors of 2 to the routing
->> table size, in theoretical limit.  I agree there is problems, specifically
->> in multi-homing.  The goal was to fix the problems with multi-homing, and
->> this was a good way to bring the problems out.  IMHO, I don't want to fix
->> the symptoms.
->
->This might lead to a trend where organizations not really needing pTLA
->assignment apply for one, instead of getting a fragment from an existing
->pTLA -- if this is the only way to avoid multihoming considerations.  I'm
->not sure about the multihoming status, but I don't think it's really
->scales up to 6bone /32's and the like, connecting dozens of sites which
->would also need to multihome or renumber -- the maximum unit is a /48 site
->at most I think.
->
->Ie. this probably leads to an increase of pTLA or equivalent
->"non-filtered" organizations which may not be good from the aggregation
->point of view either.
->
->The scaling of IPv6 wrt. routing table size is IMO a big non-issue; a
->remnant from the '95 when people started to get worried about the growth
->of DFZ.
->
->Nowadays 100,000 routes is no big deal.  Any "core" router which should be
->able to get full internet table can deal with this without problems.  You
->shouldn't be participating with your old 4500 Cisco with 16 MB of memory.
->Thus, I don't see what's the point of trying to minimize the size with all
->costs.
->
->Currently, the effectively changing IPv6 prefix size is smaller than with
->IPv4, and the population of it going to be sparser.  Also remember a big
->problem of current IPv4 routing table size are small advertisements,
->like /24 and /23 -- with IPv6 these are all within one /48, and are thus
->automatically very effectively aggregated.
->
->
->What's more worrying is complete fragmentation wrt. RIR allocations.
->Suppose all dial-up's and DSL's etc. are all given /48 as IESG requires.
->In effect, this requires RIR's take back (or assign new ones) all the
->current /35 allocations, and use a much sparser mode, like:
->
->really huge ISP's: /16
->basic block for an ISP participating in DFZ: /24
->smaller ISP: /32
->small ISP: /40
->site: /48
->
->Without this, the current scheme is bound for disaster, and not because of
->someone is filtering a little longer than /24 when /24 is a basic
->allocation.
->
->> If you are announcing
->> pTLA A's /32 to pTLA B, and this caused a problem when you moved, then you
->> have violated rfc2772 already.
->
->This is the case, but I fail to see the big problem with this.
->
->In a "perfect world", organizations in this situation would renumber, use
->multihoming or whatever; in real world both are diffcult and the problem
->is avoided by getting a pTLA on your own.
->
->-- 
->Pekka Savola                 "Tell me of difficulties surmounted,
->Netcore Oy                   not those you stumble over and fall"
->Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
->
->