[AusNOG] International link issue

[McDonald Richards]

Agreed on the RPSL front which is taken care of by the existing IRR infrastructure... If only there was a way to validate against it on a router control plane :)

Even if this method existed I imagine we would see full table convergence times go through the roof. Maybe this would stop stub ASNs requesting a full BGP feed when all they generally need is a regional subset and a default?

Macca



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

> if only it were as simple as origination validation!
> 
> The issue is describing transit policies, and for that you tend to need RPSL pretty quickly.
> 
> Geoff
> 
> 
> On 24/02/2012, at 2:00 PM, McDonald Richards wrote:
> 
>> 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
> 
> --
> 
> Geoff Huston
> Chief Scientist, APNIC
> 
> +61 7 3858 3100
> gih at apnic.net
> 
> 
> 
>