Cost per prefix [was: request for help w/ ATT and terminology]

Michael K. Smith - Adhost mksmith at adhost.com
Tue Jan 22 17:30:05 UTC 2008


Hello Bill:

> -----Original Message-----
> From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu] On Behalf Of
> William Herrin
> Sent: Tuesday, January 22, 2008 7:55 AM
> To: nanog at merit.edu
> Subject: Re: Cost per prefix [was: request for help w/ ATT and
> terminology]
> 
> 
> On Jan 21, 2008 10:28 PM, Jon Lewis <jlewis at lewis.org> wrote:
> > Is there really any point in trying to put a $ figure on each route?
> 
> Jon,
> 
> Emphatically Yes!
> 
> Right now we rely on ARIN and the RIRs to artificially suppress the
> growth of the prefix count and with it the availability of PI space.
> This is a Really Bad Thing on so many levels, but absent a viable
> market-based solution to the problem, authority-based rationing is
> really the only thing we can do.
> 
> If we can determine the cost to announce a prefix then we could
> develop a market-based solution to the problem... One where instead of
> suppressing the prefix count and dealing with it as business overhead,
> we GET PAID for announcing and propagating prefixes.
> 
> There are several market models that could work, but they all depend
> on having a reliable metric for the cost of announcing a prefix. So,
> if you think you'd like to get paid for announcing routes instead of
> continuing to give the service away for free then yes, there is a
> point to determining the cost of a prefix.
> 
Hmm, who gets paid?  It sounds like your hinting around a telco-type reciprocal payment model (correct me if I'm wrong).  Do I pay my upstreams who in turn pay there upstreams and so on and so on?  Or, is there some central, uber-authority that gets paid by all of us?  It seems to me that there are many billing models that accommodate point-to-point relationships, but I'm having a hard time coming up with a mental model of payment in the many-to-many environment in the DFZ.

Regards,

Michael Smith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 475 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20080122/952ca9fc/attachment.sig>


More information about the NANOG mailing list