On 25/02/2012 06:07, Shane Amante wrote:
OTOH, I would completely agree with Geoff's comment that the policy language of RPSL has the ability to express routing _policy_, a.k.a. "intent", recursively across multiple ASN's ... (please note that I'm specifically talking about the technical capability of the policy language of RPSL, not the actual _data_ contained in the IRR).
routing policy concerns the interaction of two classes of object (prefixes and asns) as handled between asns. Problem is, while you can describe AS interaction between ASNs and some prefix stuff between ASNs, rpsl doesn't really have proper support to link the two - i.e. tying prefixes to specific paths and all that jazz. Then again, neither do most routers. It hardly matters - without a secure means of path validation, the path is purely advisory and you can only barely trust the peer asn in the path. So RPSL isn't really a solution for describing how prefixes ought to be handled to inter-asn connectivity, and even if it were and routers could handle as->prefix mapping properly, our routers couldn't handle it for large-scale interconnection links due to configuration management limitations. Put simply, managing enormous lists of prefixes and piles of ASN paths (in regex form) causes router RPs to asplode. So from the point of view of prefix distribution control, some sort of live query system is required. To this end, rpki with as path validation (if we actually had an implementation which checked all the boxes in the draft list of requirements) might work. My point was that at the moment, it's vapour and it's not clear at this point that it will ever change into something more solid, particularly given the challenging feature list that we want it to cope with, and given the constraints of what people already do with their policy routing. And even if it does ever work, it immediately opens up an exquisitely ugly can of worms at layers 9 and above. Call me conservative, but I have not been convinced that RPKI solves more problems than it creates. Your other concerns about as path validation implementation are indeed difficult to address. Nick