Maybe you don't have the router do the authorization of the prefix. Maybe it asks another box that says yes, or no. If that box disappears you have a fallback mechanism (prefix-limit and as-path filter). Of course you still need vendor buy-in. I don't think this is realistic, so hold the tomatoes. I'm just trying to think outside the box. Certainly you have a problem when you have a catastrophic event and have hundreds of routers asking for authorization of thousands of updates. More realistically, it would be spiffy if there was a tool that would listen to your BGP and tell you about routes that don't jive with the IRR. This gives you some idea of what is going around your network that might not belong. Today not only is there the potential for abuse of peering with big providers, but there is very little that can be done in terms of identifying it. If there was a tool that tracked routes outside of the IRR you would at least know what was showing up that looked funny. Could also be a good stick to beat people in to conformance by showing who is not registering routes. Given good information on how all the IRR stuff works, I think I could write a tool like that. Is there any interest? -----Original Message----- From: Vadim Antonov [mailto:avg@exigengroup.com] Sent: Tuesday, July 16, 2002 7:56 AM To: Pedro R Marques Cc: nanog@merit.edu Subject: Re: No one behind the wheel at WorldCom

I would still contend that the number 1 issue is how you do express the policy to the routing code. One could potentially attempt to recognise the primary key is a route-map/policy-statement and compile it as you suggest. It is an idea that ends up being tossed up in the air frequently, but would that solve anything ?

Actually, expressing RP on per-router basis is kind of silly, and an artifact of enterprise-box mentality. A useful design would allow formulation of RP for the entire network with subsequent synchronization of routers with the policy repository.

Is there the ability in the backend systems to manage that effectivly and if so is text interface via the CLI the most apropriate API ?

Cisco-style CLI is extremely annoying and silly. There's no useful way to perform a switch-over to a new config, and there's no good way to compare two config and produce applicable difference. That said, I think a well-designed CLI is a powerful thing, and can be used to integrate routers with provider-specific NMSes. --vadim