"Alex.Bligh" <amb@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.