Follow up to previous post regarding SAAVIS
scg at gibbard.org
Wed Aug 12 19:43:00 CDT 2009
On Wed, 12 Aug 2009, Richard A Steenbergen wrote:
> 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.
I'd be very hesitant to use an upstream that didn't use any filtering
method. But, as convenient as I find the IRR system to be (from the
customer perspective, at least), I'm quite happy that a couple of our
upstreams use other mechanisms instead.
I've had prefixes fall out of the IRR a couple of times, leading to
outages of IRR-using transit providers. I've had transit providers screw
up manually maintained prefix-lists, or had mis-communications resulting
in the wrong thing getting removed. With multiple transit providers and
multiple systems, they tend not to all have the same filtering problem at
the same time. That's a very good thing.
I hope the recommendation that comes out of this discussion is to filter
somehow, rather than to use any particular filter-generation mechanism.
Diversity and redundancy are good things, in processes as well as
More information about the NANOG