Sean Doran wrote:

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

Well I guess it would be difficult to tell.

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.

Yup. I understand exactly why you have done that, and think its sound logic. At 19 bits it doesn't cause me any significant pain either - and it shouldn't cause anyone else any either.

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.

Yep. But if we couldn't tell the customer is routing was suboptimal (i.e. if we did have full automation or if noone filtered) we might be back to square 1 as suboptimal routing is a "scary thing" to wave at the customer to encourage them to renumber :-)

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

... and so are we :-) However, in many of the circumstances I've been involved in what needs automating is network engineering at the *old* provider :-) It would be interesting if the RA et al monitored announcements of more specific routes, and differentiated those which were a) In IRR b) Not in IRR, but 'long term and stable' c) Neither of the above I guess what you are saying is 90% fall into (c). Alex Bligh Xara Networks