See now we are back to the catch 22 that is IRR. No one will use it because the data isnt there, and no one will put the data into it because no one uses it.
I think the way to get IRR into the real world production realm, is to really drive home the issue w/IPV6.
See now we are back to the catch 22 that is IRR. No one will use it because
the data isnt there, and no one will put the data into it because no one
uses it.
[CC: list trimmed]
Actually, I think you'll find that bad data is only a small part
of the problem; even with good data, there isn't enough support from
various router vendors to make it worthwhile; it's effectively impossible
to prefix filter a large peer due to router software restrictions. We
need support for very large (256k+ to be safe) prefix filters, and the
routing process performance to actually handle a prefix list this large,
and not just one list, but many.
IRR support for automagically building these prefix lists would
be a real plus too. Building and then pushing out filters on another
machine can be quite time consuming, especially for a large network.
I think the way to get IRR into the real world production realm, is
to really drive home the issue w/IPV6.
This still doesn't solve the scaling issue. This is no different
than running your own RR, which many ISPs already do -- and they still
have to exempt many of their peers. Typically, RR derived prefix filtering
is something reserved for only their transit customers.
If it were that easy, everyone (well, some people) would be
doing it.
--msa
There are different types of filter tho and I'd suggest they are suitable in
different circumstances.
eg
small peer < 100 prefixes - build prefix filter list, as path list
middle peer - either depending on requirement (eg cust, peer)
large peer > 1000 prefixes - as path filter plus max prefix
I'm not implementing the above so the numbers and suggestions are a little
arbitrary but I'm making the point that you can filter smaller peers who are
less experienced and more likely to give an error and for larger peers you have
to be less granular but can still impose failsafes without increasing CPU.
Steve
maxprefix makes sense here too on a Juniper router since it applies
maxprefix to the _received routes_ (not to the routes after filtering
as Cisco does it).
tschuess
Stefan