Follow up to previous post regarding SAAVIS

Frank Bulk frnkblk at iname.com
Thu Aug 13 00:37:00 UTC 2009


Perhaps this is a stupid question, but does each SP need to run their own
physical RR?  Isn't this something that could be hosted?

Frank

-----Original Message-----
From: Richard A Steenbergen [mailto:ras at e-gerbil.net] 
Sent: Wednesday, August 12, 2009 5:55 PM
To: Joe Provo
Cc: nanog at nanog.org
Subject: Re: Follow up to previous post regarding SAAVIS

On Wed, Aug 12, 2009 at 05:41:03PM -0400, Joe Provo wrote:
> Most ISPs don't have that level of management clue & willpower, as the 
> same "but they will go to $competator who doesn't require it!" which 
> has screwed up everything from domain registration to responsible BGP 
> announcements fouls the customer interface as well. Account reps wanting
> an exception 'just this once' are the norm.

I would make the opposite argument, my business would NEVER go to any
network which didn't support IRR (and a bunch of other simple but
important things, like a full set of non-secret BGP communities). It's
amazing the number of networks that excludes in this day and age. And 
not even because "omg IRR is good because someone told me so and we 
should support it", but because I've seen FAR too much grief caused by 
humans typoing prefix-lists, or taking days to process them. It is the 
height of absurdity that this would ever be considered an acceptable 
solution to the problem.

But most of all I'm amazed that we as network operators have managed to 
take such a simple concept as a protocol for storing and recursively 
retrieving a list of prefixes in a database and turned it into such a 
sloppy mess. We really shot ourselves in the foot with the complexity of 
RPSL, which tries to be everything to everyone rather than actually 
provide a simple effective way to maintain prefix-lists.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)






More information about the NANOG mailing list