Re: Customer AS

["Alex.Bligh" <amb () xara net>]

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



- - - - - - - - - - - - - - - - -