<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 24/02/2012, at 1:30 PM, McDonald Richards wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>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.<br><br>The next challenge is getting it into the router control plane...<br></div></blockquote><div><br></div>There's tools for doing that.  rtconfig or irrpt <a href="http://sourceforge.net/projects/irrpt/">http://sourceforge.net/projects/irrpt/</a> for something more lightweight.</div><div><br></div><div>MMC</div><div><br><blockquote type="cite"><div><br>Macca<br><br><br><br>On 24/02/2012, at 1:51 PM, Geoff Huston <<a href="mailto:gih@apnic.net">gih@apnic.net</a>> wrote:<br><br><blockquote type="cite">On 24/02/2012, at 12:13 PM, Aaron Swayn wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">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 <a href="onhttp://www.potaroo.net/">onhttp://www.potaroo.net/</a> 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)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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!<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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!<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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. <br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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. <br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">So the question I have is - how can we make a route registry process efficient, accurate, consistent, workable and generally useful? <br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">cheers,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> Geoff<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">AusNOG mailing list<br></blockquote><blockquote type="cite"><a href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a><br></blockquote><blockquote type="cite"><a href="http://lists.ausnog.net/mailman/listinfo/ausnog">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br></blockquote>_______________________________________________<br>AusNOG mailing list<br><a href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a><br>http://lists.ausnog.net/mailman/listinfo/ausnog<br></div></blockquote></div><br></body></html>