Cost per route

Alan Barrett apb at IAFRICA.COM
Thu Feb 6 04:28:12 EST 1997


> As for the ISPs that block -- well, I think that they may eventually have
> a lot of explaining to do.  The reason for this is that the incremental
> cost of carring a route for a /24 is the same as for a /8.  If the ISPs
> want to be "common carriers" (and hence obtain many protections against
> being liable for the content of the traffic they carry) they may have to
> fairly offer their services to all comers.

Carrying a route has both a cost and a benefit.  The costs depend chiefly
on memory usage, flap frequency, and the effort of keeping filters up to
date.  The benefits depend chiefly on the utility of being able to reach
hosts inside the address block.

The cost per route would appear to be independent of prefix length, as you
said.  However, routes that cover many hosts are likely to carry a greater
benefit per route.  Also, routes that cover many interesting destinations
are likely to be associated with infrastructure that is engineered to be
less likely to cause route flap.  So we see that routes that cover many
destinations have a higher benefit (we're more likely to want to get to
some of those destinations) and a lower cost (the routes are less likely
to flap) that do routes that cover fewer destinations.

Notice that I was careful to talk about the number of destinations behind
the route, rather than the length of the prefix.  A /8 prefix with 10
hosts behind it costs the same as a /28 prefix with the same 10 hosts
behind it, and has the same benefits.

However, if the registries do their jobs well[*], we would expect a very
strong correlation between prefix length and number of hosts behind a
route.  Thus, it is a reasonable first approximation to assume that longer
prefixes have higher costs (due to more flap) and lower benefits (due to
fewer useful services) than do shorter prefixes.

--apb (Alan Barrett)

*  See, this message is (only just) on topic for naipr.  But perhaps
   we should move this discussion to piara.





More information about the Naipr mailing list