Home page logo

nanog logo nanog mailing list archives

Re: PI space and colocation
From: "Stephen Sprunk" <stephen () sprunk org>
Date: Wed, 18 Jan 2006 16:49:18 -0600

Thus spake "Chris Adams" <cmadams () hiwaay net>
Once upon a time, Patrick W. Gilmore <patrick () ianai net> said:
It adds zero useful data to the global table, but increases RAM, CPU,
etc. on every router looking at the global table.

How much difference is there between one AS (the colo provider)
announcing a prefix and another AS (the customer) announcing it through
the first AS (the colo provider)?  If the space is ARIN assigned PI, it
isn't going to aggregate with the colo provider's space, so the prefix
will still be a separate announcement.  The only difference is the AS
path is one entry longer.

Routing slots aren't the only resource you're consuming. In general, many of the prefixes coming out of a given AS have common attributes, e.g. path, MEDs, etc. Those attributes are stored only once (at least in the BGP implementation I know) even if they're used by hundreds of prefixes. If you attach a new leaf AS, it must, by necessity, consume another one of those slots. If the customer prefix were announced by the upstream, however, it would not require an additional attribute slot; it'd reuse one of the existing ones.

Now, I'm not aware that there's any serious shortage of attribute slots like there is routing slots, but there's no sense wasting them if there's no gain to be had doing it. Save your (and everyone else's) RAM for more prefixes.


Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]