Customer AS

Sean Doran wrote:

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

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 :slight_smile:

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

... and so are we :slight_smile: However, in many of the circumstances
I've been involved in what needs automating is network
engineering at the *old* provider :slight_smile:

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