Curtis,
I agree that the majority of more specifics are mistakes. We use the
IRR to separate out the inintentional mistakes (the redundancy in that
statement was intentional:). This does protect us against the all too
common case of too ignorant of CIDR to know better and registering the
more specific in the IRR anyway (the intentional mistakes).
Really? I would agree that the majority of more specifics are not in
the IRR. This doesn't necessarilly mean they are mistakes. For instance
we announce a pile of more specifics from other provider aggregates
(intentionally, and with permission) where a customer is renumbering.
These get filtered by Sprint (because they are too long prefixes),
and by ANS (as they aren't in the IRR), but the idea is we propogate
these more specifics as close as possible to the major networks
as possible, so that as far as possible we aren't using the
old providers transit to transit these routes (for several
obvious reasons). 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.
So I have no problem with either ANS or Sprint's filters, just
don't think *all* non-IRR entered more specifics are mistakes.
Alex Bligh
Xara Networks
"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.