PI space and colocation

Wed Jan 18 23:22:04 UTC 2006

> 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.

I think that this deserves a bit more explanation...

Most implementations use an "attribute cache".  An entry in this  
cache typically consists of a
set of different attributes.  Which attributes constitute a cache  
entry is entirely up to the
implementation.  Each prefix will have a number of paths.  Each path  
will point to an attribute cache entry and also contain one or more  
other uncached attributes.  Individual attributes themselves
may also be cached.

The primary attribute cache may or may not include the AS path.  If  
it does not, it is very likely
that there is a cache for the AS paths.  Again, this is all  
implementation dependent.

If an implementation does cache AS paths independently from the  
attribute cache, then the cost
of a stub AS is only one more AS path entry in the AS path cache.  If  
an implementation
does not cache AS paths independently, then creating a stub AS will  
create a new
attribute cache entry, complete with AS path.

Regardless of this, it should be noted that this is only using BGP  
table RAM.  This should not
affect the main routing table or the forwarding table.  Having an  
additional PI prefix in the
first place is the expensive part, as that does consume BGP RAM,  
routing table RAM and
forwarding table entries.

IMHO, wasting any resource is unfortunate, but the cost of additional  
forwarding table entries
far outstrips the cost of additional DRAM.  Thus, adding an  
additional prefix does merit
a significant shout from others, but the stub AS should only be an  
incremental whimper.

Regards,
Tony