[AusNOG] International link issue

[Aaron Swayn]

I was thinking the same thing.. getting the data together is the easy bit IMO, but interacting with the control plane in near-real time will be interesting. I'm surprised the vendor's haven't jumped onto this one yet. We can do IDP, AV, CF, etc but not linking prefix filters to external DB's seems simple, but I'm no JunOS/IOS designer either.

Someone should put in a feature request. :)

-----Original Message-----
From: McDonald Richards [mailto:macca at vocus.com.au] 
Sent: Friday, 24 February 2012 2:01 PM
To: Geoff Huston
Cc: Aaron Swayn; Ausnog at ausnog.net
Subject: Re: [AusNOG] International link issue

Tie route registrys in with the address registrys. Make a prefix owner elect an origin ASN at the RR level and come up with a system for delegation.

The next challenge is getting it into the router control plane...

Macca



On 24/02/2012, at 1:51 PM, Geoff Huston <gih at apnic.net> wrote:

> On 24/02/2012, at 12:13 PM, Aaron Swayn wrote:
> 
>> I’ve seen Mr BGP, Geoff Huston lurks on these forums from time to time (I think he appeared a few day ago). Might be a good time to suggest his next monthly column onhttp://www.potaroo.net/ for March to cover ISP BGP peering design. Seems the list has some significant interest in how, where, why and best practices. I believe Geoff has written a few books on ISP’s over the many years and could share some valuable insights (and maybe some war stories too from his days at Telstra)
>> 
> 
> 
> I'll let the Telstra folk talk about Telstra - it's been many years since I worked for them so no doubt much of my recollections about their network are out of date in any case.
> 
> But more generally I'd offer the advice to _always_ use route filters in BGP for your customer and peer links. And that applies to your outbound advertisements as well as filtering inbound advertisements. So its incumbent on both parties to exercise control - this kind of belt and suspenders multiple control structure ensures that single typo problems should not escalate into exported routing nightmares!
> 
> And that way you can hopefully avoid the worst of the third party damage from fat finger slip ups that we all (me too in past years) do from time to time, and if you do stuff up then with filtering in place the network you damage should be limited to just your own!
> 
> On the topic of how to maintain route filters, I was never a big fan of route registries in the past, but this is something that I'm coming around on. To get everyone to spend the time to maintain their own RRDB entries and keep them up to date has always been a massive ask, and in the past I was ready to condemn route registries as being little more that a collection of amorphous data, some of which was real and current, some of which was historic or just plain wrong, and no way to tell which was which. 
> 
> But frankly we really don't have any alternative as far as I can see. In this case routing security won't help at all, and we really have nothing else around. But I have to also observe  what we are doing at the moment is pretty lousy and adherence is piecemeal (e.g. yesterday's route leak) - many providers and exchanges operate their own route registries (or not!), and an ISP with multiple external connections has to take on a maintenance task of maintaining routing information in a number of provider and exchange databases. There really has to be a better way to do this. 
> 
> So the question I have is - how can we make a route registry process efficient, accurate, consistent, workable and generally useful? 
> 
> cheers,
> 
>  Geoff
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog