Towards a Disjoint IRR

In message <199504282104.AA19969 at zed.isi.edu>, bmanning at ISI.EDU writes:
> > 
> > Dale,
> > 
> > I support your view that a disjoint IRR is the correct vision, since
> > 
> 
> While I tend to agree with Eric, I can see this model as being potentially
> hostile to people who are either having specific difficulties with a specific
> registration authority who may use this tacit agreement to "lock" registratio
> ns.
> 
> As I pointed out elsewhere, while the registry may belong to the registration
> authority (nee ISP) the data in it belongs to the end user.       
> 
> We should ensure that there are tools to address/deal with duplications and
> making accurate determinations on which entries to beleive.   
> 
> 
> --bill


Why doesn't this seem like a problem to me?  The RADB concentrates
data from CANET, MCI, ANS, anyone else with a registry in North
America and also bring in data from the other continents.  CANET would
consider their own information authorative for CANET and their
secondary mirror of RADB (if they run a secondary to keep things
local) as authorative for everything not covered locally.  Same with
MCI, ANS, anyone else, consulting their own data first.  The RADB
would run secondary for CANET, MCI, ANS, etc, and primary for
registeries that didn't fall into any of the above.

If someone moves between providers, their old ISP could potentially 1)
fail to remove the peering from inet-rtr (so what), 2) fail to put a
"hole" in their route object, 3) fail to remove the AS from an AS
macro, 4) fail to adjust their policy to accept the announcement of
the hole in their aggregation.  I don't think 2) is an issue.  If
explicit policy for an AS overrides an AS macro, then 3) is not an
issue.  The only issue is 4) because the the customer couldn't route
traffic through their old provider if their old provider generated
their configs reflecting their registry.  It wouldn't affect policy
outside that AS though, nor would it affect policies of other AS as
long as the route object could get into some registry (their new
provider or primary at the RADB).

This simply goes back to the question of how big a prefix must be to
justify moving out of a CIDR block without renumbering.  Yes, this is
a problem.  The registry would reflect the situation if some providers
routed the small more specific block and other didn't.  If numerous
providers chose not to route prefixes below a certain size, then it
would give the customer a means of assessing whether to renumber.
(Based on empeircal evidence it might boost the volume of their
complaints on the mailing lists first).

This is a problem, but why is this a registery problem?  Am I missing
something?

Curtis



-------- Logged at  Mon May 1 15:54:56 MET DST 1995  ---------