Slightly related, this was posted only in the last few hours: http://mailman.nanog.org/pipermail/nanog/2012-February/044747.html (Did this inspire your comments Jamie or is it just remarkably coincidental?) This and the followups tell the truth about IRRs, I think; effective when used, but it's only the good players who use them properly. NZ being largely made up of good players, perhaps it would add value, if only when dealing with the US-based types who would be able to use it as another positive reputational move? (still, to this day, finding providers in the USA and Canada who muck with TCP coming out of NZ due to the poor reputations of our more Asian-centric counterparts also taking APNIC delegations). Mark. On 01/02/12 23:30, jamie baddeley wrote:
thanks.
I was pondering the lack of interest expressed by the conference in adopting IRR entries. Back in the day when we deployed the anycast network for the geonet reporting system, we ran into our the geonet prefix not being picked up by US peers. We loaded that prefix into IRR and up things came as the US folks auto build their import filters at the peering points based on what's in the IRR registries.
Got me wondering whether NZ Purchasers of Internet transit to the US are getting the full benefits of their service (i.e. their foreign peers picking up all prefixes) as we'd be relying on the transit providers to create the IRR proxy objects.
Populating IRR for kiwi providers is an extra step, but I do wonder if it'd result in shorter paths stateside (assuming the international transit guys aren't as sharp on proxy objects as we'd like)
I'm not an Ops guy now - there's far smarter guys than me in the team to do that now. But my take is populating the IRR is it is best practice to do so, and every step we take to improve latency is a good thing right?
Isn't the other thing is that populating the IRR is the 1st step towards what seems to be a plan to prevent prefix hijacking with RPKI? Where's that whole initiative at these days?