hierarchical route objects, part 1

In message <9701151915.AA17947 at jade.noc.dfn.de>, Joachim Schmitz writes:
> 
>  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)

How about if the routing-wg does the right thing and leave the RA and
InterNIC to either cooperate with each other or the RA to ftp and fill
in inet-nums or disable the feature (hopefully not the latter).

> > 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...

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.

>  Regards
>     Joachim

Regards,

Curtis