Re: 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@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) _____________________________________________________________________________
In message <9701151915.AA17947@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
participants (2)
-
Curtis Villamizar -
Schmitz＠RUS.Uni-Stuttgart.DE