hierarchical route objects, part 1
- Previous message (by thread): hierarchical route objects, part 1
- Next message (by thread): hierarchical route objects, part 1
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Curtis Villamizar
curtis at ans.net
Thu Jan 16 01:07:38 CET 1997
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
- Previous message (by thread): hierarchical route objects, part 1
- Next message (by thread): hierarchical route objects, part 1
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]