hierarchical route objects, part 1

 Dear Curtis, dear David,

 you both wrote:
> > > Your black hat example is also flawed.  At the top of the heirachy can
> > > be 0/0 registered to IANA and withdrawn (not announced).  The
> > > registries themselves can have top level objects below that.  In order
> > > to make any changes, you need to have been given authorization from a
> > > higher level.  You can then assign authorization to lower blocks to
> > > other parties.
> > 
> > This works for IP network objects since the registries need to add these
> > objects manually anyway.
> > 
> > This is not that obvious for 'route' objects. Are you proposing that the
> > registries have to approve (manually) all the route objects that are
> > in the route hierarchy directly below their own allocated space ?
> 
> Tie the hierarchy to the inetnums.  Continue to flog the InterNIC for
> non-participation in the IRR.  The maintainer of a database such as
> the RADB that uses InterNIC as the number registry may have to take
> InterNIC data (ftp) and load it into inetnum records.
 I wonder about the effort necessary to do this.
 Moreover, we should not forget about pure routing registries - they would
 be forced to include inetnums as well (and I wonder whether they are
 willing to do so)
> 
> An inetnum references one or more maintainer (in mnt-by).  To create a
> route object, you must satisfy one of the criteria:
> 
>   1.  You must be in the maintainer field in a less specific route
>       object (used to create route objects for more specific prefixes;
>       hopefully these get aggregated somewhere ).
> 
>   2.  You must be in a maintainer for the exact inet-num and for the
>       AS that you are putting in the route object (used after the
>       initial top level route object is created).
> 
> Once a top level route object is created, a more specific route object
> can be created and the mnt-by field can reference more than one
> maintainer.
> 
> 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...

 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)
_____________________________________________________________________________