sub-allocations or something similar
Hello there colleagues, for some last years I'm working with RIPE DB I think it would be useful to have some kind of "sub-allocation" inetnum objects. Brief example in our current situation: there is downstream provider behind us, currently without its own address block, so I've assigned /21 for them. All that space was of course well-documented, with ripe-141's covering all the nets, and appropriate inetnum objects have been created. But, for aggregating purposes, I suppose aggregating inetnum for the whole /21 would be useful and self-documenting. I can create such object, but such object is considered as overlapped. I think about explicit route-object also, but size behind current minimum allocation size (/19 for 195/8 or /20 for newer) somewhat stops me :) Your (both community and especially RIPE NCC people) suggestions are strongly expected ;-) Thank you. Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------
Hi, isn't that already on the way, called LIR-ALLOCATED? A proposal by James Aldrige... But I don't have any clue about the current status. Cheers, Carsten Dmitry Morozovsky wrote:
Hello there colleagues,
for some last years I'm working with RIPE DB I think it would be useful to have some kind of "sub-allocation" inetnum objects. Brief example in our current situation:
there is downstream provider behind us, currently without its own address block, so I've assigned /21 for them. All that space was of course well-documented, with ripe-141's covering all the nets, and appropriate inetnum objects have been created. But, for aggregating purposes, I suppose aggregating inetnum for the whole /21 would be useful and self-documenting. I can create such object, but such object is considered as overlapped.
I think about explicit route-object also, but size behind current minimum allocation size (/19 for 195/8 or /20 for newer) somewhat stops me :)
Your (both community and especially RIPE NCC people) suggestions are strongly expected ;-) Thank you.
Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------
Hi, we are indeed working in implementing the LIR-ALLOCATED proposal. The work involves some changes to the RIPE DB (inetnum objects need to be redefined so that the primary key is not only the IP range) AND some work in the hostmaster tools so that people don't get nagged about overlaps when they send tickets to the RIPE NCC hostmasters. Having said that, I am not quite sure what Dmitry was looking for was this because he is trying to express aggregation (which ought to be expressed by a route object) and not re-allocation. Right now LIR allocations are already covered by the inetnum object with the ALLOCATED PA status. Then again, I must be missing something so I would like to see some more on this to try to get the requirements right and then work on them. Regards, Joao At 13:37 +0200 18/7/01, Carsten Schiefner wrote:
Hi,
isn't that already on the way, called LIR-ALLOCATED? A proposal by James Aldrige...
But I don't have any clue about the current status.
Cheers,
Carsten
Dmitry Morozovsky wrote:
Hello there colleagues,
for some last years I'm working with RIPE DB I think it would be useful to have some kind of "sub-allocation" inetnum objects. Brief example in our current situation:
there is downstream provider behind us, currently without its own address block, so I've assigned /21 for them. All that space was of course well-documented, with ripe-141's covering all the nets, and appropriate inetnum objects have been created. But, for aggregating purposes, I suppose aggregating inetnum for the whole /21 would be useful and self-documenting. I can create such object, but such object is considered as overlapped.
I think about explicit route-object also, but size behind current minimum allocation size (/19 for 195/8 or /20 for newer) somewhat stops me :)
Your (both community and especially RIPE NCC people) suggestions are strongly expected ;-) Thank you.
Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------
--
On Wed, 18 Jul 2001, Joao Luis Silva Damas wrote: JLSD> we are indeed working in implementing the LIR-ALLOCATED proposal. Sounds great ;-) Are there any online resources with specifications or something about? JLSD> Having said that, I am not quite sure what Dmitry was looking for was JLSD> this because he is trying to express aggregation (which ought to be JLSD> expressed by a route object) and not re-allocation. Right now LIR JLSD> allocations are already covered by the inetnum object with the JLSD> ALLOCATED PA status. Not fully; as I said before, this exact case involves sub-provider without his own address space, so re-allocation would be rather flexible and appropriate solution, AFAIK.... JLSD> Regards, JLSD> Joao Thanks, Joao, for your attention. Have a nice weekend ;-) Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------
Dmitry Morozovsky wrote:
On Wed, 18 Jul 2001, Joao Luis Silva Damas wrote:
JLSD> we are indeed working in implementing the LIR-ALLOCATED proposal.
Sounds great ;-) Are there any online resources with specifications or something about?
My proposal is at http://www.mcvax.org/~jhma/ripe/lir/lir-allocated.html Regards, James -- James Aldridge, Senior Network Engineer (IP Architecture) KPNQwest, Singel 540, 1017 AZ Amsterdam, NL Tel: +31 70 379 37 03; GSM: +31 65 370 87 07
participants (4)
-
Carsten Schiefner -
Dmitry Morozovsky -
James Aldridge -
Joao Luis Silva Damas