hierarchical route objects, part 1

 Dear Curtis,

 you wrote:
> > > Here is an example.  The registries approve of the top level blocks,
> > > that is the aggregates (or blocks that should be announced as
> > > aggregates).  Whoever the aggregate is allocated to creates the top
> > > level route object and can delegate below that.  For example, ANS has
> > > 207.24/14.  There were two route objects needed to handle multihomed
> > > (a /22 and a /24) prefixes.  The usual way a provider would delegate
> > > would be to reference more than one maintainer in the route object
> > > (the provider and the customer, and probably the other provider if the
> > > route object had a unique origin AS).
> > > 
> >  This scheme sounds reasonable but it raises the question of coordination
> >  among different registries...
> 
> I would not expect to see the same address space allocated by more
> than one registry.  All registries would have a top level 0/0 route
> object which prevents registry of bogons.  RIPE would have a hierarchy
> under 0/0 and the RA would have a hierarchy tracking InterNIC assigned
> addresses.  I would not expect the two to overlap, therefore there is
> no real coordination problem beyond initial setup or new blocks
> allocated to a registry.
> 
 This is more difficult than it looks from the beginning. As an example
 we ourselves register all our objects (inetnum, routes, persons...) in
 RIPE database (because we are in Europe). However, among others we peer
 with MCI and MCI insists on having route objects in their registry in
 order to allow routing. If the route objects are secured by hierarchical
 authorisation in the RIPE database we would also like to have them secured
 in the MCI registry. Following the scheme above MCI would have to include
 inetnums (while it is a pure routing registry) *and* would have to generate
 top level route objects allowing specific access by us to our route objects
 (this is a very tiring job especially regarding "the swamp" 192.x).
 Of course, they could copy from RIPE database... (ask them why they don't...)
 I guess, this problem may only be resolved by the GRR (which is yet to come)

 From the ongoing disussion I conclude for myself (at the current state of
 the discussion) that we can not impose a strict security mechanism at the
 time being without breaking too many things. Maybe, I am too dumb to see
 a simple solution which might be just at hand...

 I will summarise the things said here on the mailing list for the routing
 wg session next week and try to think some more about it (I guess, Daniel
 was right from the start when he said that we should begin with a bare
 notification mechanism...)

 Regards
    Joachim
_____________________________________________________________________________

 Dr. Joachim Schmitz                                   schmitz at noc.dfn.de
 DFN Network Operation Center
 Rechenzentrum der Universitaet Stuttgart              ++ 711 685 5553 voice
 Allmandring 30                                        ++ 711 678 8363  FAX
 D-70550 Stuttgart                                     FRG (Germany)
_____________________________________________________________________________