Towards a Disjoint IRR

Bill, 

I agree that there are locking, authentication and audit trail (or
credibility) issues with a distributed registry. I think that this
administrative & process infrastructure is a very important issue to
face.  The problem is the same in the phone network; they call it
slamming, we call it "route poaching" leading to "CIDR MADness"[1].
Sean's "no mask longer than x" policy is an interesting strategy for
national network defence. ;-) However, the bottom line is that there
is no central registry in the Internet today from a practical
perspective, and I think multiple registration models the problem
better than central registry. It should be noted that in many cases,
there is *no registry* mediating between some providers.

For example, if there are multiple ISPs annoucing a route, I believe
it is better to know that fact than have them do it silently. This
permits static analysis of conflicts and reporting. This multiple
conflicting registration *already* happens with the PRDB, assuming the
current RA-less NAPs or MAE-E. Say, for example, I have X, service
provider Z has X too, and announces it. Today, I prefer X locally, Z
prefers X locally, AS690 and those behind it prefer what's in the
PRDB, and everyone else, all bets are off. At least, if someone runs
static analysis, I know that someone grabbed "my" route. I can then
alert to the customer, and find out what should be happening. This is
in fact what just happened recently.

What I think shows promise is the digital signature strategy in the
delegation & registration. This permits a customer to say for sure
that they want to be in vendor Zs registry. The audit trail is
preserved, and the credibility of the delegation & registration is
established. The hard part for the customer is *revoking* that routing
registration. This problem comes in two parts: routing registry
registration and actual implemented routes interior to the old vendor.
This is especially difficult in the face of heavy use of static
routes. I cannot count the times a customer has transitioned, and the
static simply remains on the old vendor's network, black-holing some
large part of the customer's reachability.

Eric Carroll	University of Toronto Network & Operations Services
		External Networking Facilities Management
		CA*net Network Engineering

[1] CIDR MADness - CIDR Mutual Assured Destruction - two-vendor
iterated escalation the length of the mask for a given customer route
in order to recover primary control of a route intiated when one
vendor registers a longer-mask subaggregate of an overall agregate
registered by a second vendor.

I have been meaning to actually write that down since we talked in
Colorado. :-)



-------- Logged at  Sat Apr 29 04:11:15 MET DST 1995  ---------