One might suspect there are some things we can learn from this:
http://tools.ietf.org/html/rfc4641 In particular, when *contrasting* even initial operational practices with preceding recommendations made in theoretical environments, a disparity usually emerges. I share concerns about frequency of publication and fetching functions. In particular, this was one of the larger reasons why folks stopped using IRR-based prefix lists in practice. It's a real PITA when intermediate ASes haven't updated policies for newly announced prefixes in a stateful protocol such as BGP. The originator announces the route, the route is dropped by peers because it's not permitted in the import policy, then the policy is updated eventually after corresponding IRR objects were fetched and the route is now permitted in policy, but stateful BGP doesn't reannounce the route, so the route had to be "bounced" somehow along the path, or at the origin, or a session reset to trigger a new update once the policy has been updated. Of course, we have BGP route refresh today, and implementations arguably should store an "invalid" route in an Adj-RIB-In and denote as such - but that does introduce cost (and a potential attack vector) as well. As Randy pointed out, and Curtis and I have stated (and lived firsthand together :-/) many times, the ripple effects associated with disjoint and autonomous application of policy derived from IRR (or RPKI) like systems are quite an operations nightmare in practice, and should be given heavy consideration here. -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
