Customer AS

Mon Aug 19 21:37:43 UTC 1996

"Alex.Bligh" <amb at xara.net> writes:

> So I have no problem with either ANS or Sprint's filters, just
> don't think *all* non-IRR entered more specifics are mistakes.

I don't think Curtis was suggesting that all non-IRR
registered more specifics are mistakes, but rather the IRR
is what he bases his filters on, because most such more
specifics appear to be mistakes.

This is what I'd consider a 90+% engineering guess, and 
seems reasonable to me.

On the other hand, I wouldn't suggest that all prefixes
longer than 19 bits are mistakes or are unstable, but I
have observed that most appear to be, and so the
engineering decision on this side was to filter them out.

The problem here is that the minority of situations when a
long prefix or an unregistered more specific route is
needed for a short time, you're stuck with:

> We don't put advisories or more specifics in the
> IRR for several reasons, not least of which because this is a temporary
> arrangement, and sorting out changing guardianship of the RIPE
> objects etc. etc. with the old provider who is often slow to
> cooperate is simply not worth the hassle.

or conversely, the length of time it takes to change
inbound prefix-length filters and have BGP peerings with
external peers updated or reset to take the changes into
effect.

Both types of delay are crying out for automation, to
reduce the delays, and add further flexibility into
filtering policies.  That, of course, means that someone
has to develop the automation.  I think you will find that
ANS and Sprint (like many others) are both hiring... :-)

	Sean.