Subject: [GROW] I-D Action: draft-ietf-grow-irr-routing-policy-considerations-05.txt

From: [email-masked]
Date: Wed, 27 Aug 2014 13:30:13 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Global Routing Operations Working Group of the IETF.

        Title           : IRR & Routing Policy Configuration Considerations
        Authors         : Danny McPherson
                          Shane Amante
                          Eric Osterweil
                          Larry J. Blunk
                          Dave Mitchell
	Filename        : draft-ietf-grow-irr-routing-policy-considerations-05.txt
	Pages           : 18
	Date            : 2014-08-27

Abstract:
   The purpose of this document is to catalog past issues influencing
   the efficacy of Internet Routing Registries (IRR) for inter-domain
   routing policy specification and application in the global routing
   system over the past two decades.  Additionally, it provides a
   discussion regarding which of these issues are still problematic in
   practice, and which are simply artifacts that are no longer
   applicable but continue to stifle inter-provider policy-based
   filtering adoption and IRR utility to this day.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-irr-routing-policy-considerations/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-grow-irr-routing-policy-considerations-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-grow-irr-routing-policy-considerations-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 29 Aug 2014 12:04:56 +0100

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