larger issues which acted as disincentives to IRRDB routing policy management
- rpsl is poorly specified
- rpsl didn't keep up to date with technologies.
- https://lists.isc.org/pipermail/irrtoolset/2011-April/000736.html
- it may be useful to see some discussion on the state of the IRRDB
toolkits. E.g. the reference implementation irrtoolset was always
incomplete, badly written and none of the other toolsets (rpsltools, bgpq3,
etc) only ever attempted to cherry pick tiny subsets of the rpsl specs
- the garbage-in, garbage-out problem: there are inadequate control
mechanisms in the IRRDBs to stop arbitrary people from adding arbitrary
garbage to their as-sets and prefix lists, which means that it is dangerous
to depend on them as the sole means for handling inter-domain prefix
distribution. INEX did this at one stage, until the day that someone added
AS-SET-INEX-RS to their own as-set, then accepted all prefixes from the
INEX route servers, distributed them into their IGP, then redistributed
them back into BGP with origin-as == local-as and then reannounced them
into the INEX route servers.
While a tiny bit of me is in awe at the level of ingenuity that caused this
catastrophic sequence of events, it also highlighted that no matter what
safety mechanisms you put in place, you'll always find someone who can
manage to break them unintentionally.
nits:
illusive -> elusive
there is a fundamental limitation that still exists -> fundamental
limitations still exist
the external and systemic dependencies ... networks, introduces -> the
external and systemic dependencies ... networks, introduce
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
