[ppml] Draft 2 of proposal for ip assignment with sponsorship

william at elan.net william at elan.net
Fri Feb 28 09:11:05 EST 2003

> > that companies'  servers. So you customers are not able to get to that
> > network and your  competitor next door are because they do not do
> > summarization. Who is the  winner here, your users or your competitor's
> > users?
> I'm not saying it is necessarily a 'good thing' to summarize.  However, the 
> situations where backbone providers are forced to filter the way I see it 
> are situations where the alternative is to shutdown their entire network. 
> Wouldn't you agree that it is important to keep a large network running in 
> such a case, even if it degrades the multi-homing for some customers?
ARIN makes it very clear when they assign the ip block that they do not 
guarantee routability. So provider with serious network issue would be 
free to filter out all the small blocks (do any do that now for swamp 
space?) and those who receive micro-assignments should understand that 
they maybe taking a risk when receiving such an ip block. It would also be 
up to the ISP that they contact to try to explain to them what would 
happen but in the end I believe its up to end-user to decide if they would 
benefits or not from micro-assignment and if they believe the benefit is 
bigger to them then the risks, there should a procedure for them to get 
such a miro-assignment from ARIN.
> > How am I not correct if on the same RIPE document it says "Allocations or
> > assignments smaller than the default size have been made to users
> > requesting Provider Independent (PI) IPv4 address space." (did I see /29
> > there above?).
> Look at the blocks.  Those are ancient (swamp) blocks (193/8, 194/8, 
> 195/8).  The recent ones are /20 and /19 (62/8, 80/8, 81/8, 82/8).
Some of these blocks RIPE received very recently (year ago). Also as you 
pointed out RIPE is very very conservative about ip assignments and 
allocations and I'v heard some really nasty things said about their 
policies and how ARIN community does not want ARIN to be like RIPE.

But to the point they are conserving space and reusing the same blocks for 
micro-assignments especially since these blocks can hold a lot more 
micro-assignments then new block can hold larger allocations. I would 
expect the same for ARIN that they would first try to reuse old swamp 
space and then assign one particular /8 for micro-assignments but not use 
any other blocks for it. That is part of my other proposal.

> > And do note that by RIPE's definition and the name itself LIR (Local
> > Internet Registry) does not necessarily have to be an ISP, it can be
> > organization dedicated to subdelegating space to ISPs somewhat in a way
> > RIR does (so they could fragment the space in routing table, but this is
> > obviously discoraged).
> >
> > But to be more to the point RIPE has a procedure in place on how LIR can
> > do micro-assignments (they call it Provider Independent Address Space):
> > http://www.ripe.net/training/lir/material/slides/page103.htm
> > http://www.ripe.net/training/lir/material/slides/page106.htm
> > By that procedure LIR can request PI space on behelf of the end-user and
> > then RIPE assigns that space to LIR and LIR to the end-user. This
> > procedure seems somewhat similar to what I'm proposing in that ISP as
> > direct contact  with end-user first checks the request and then sends it
> > to RIR and RIR  assigns the space, the difference is that in my proposal
> > end-user becomes  client of RIR where as with RIPE's system, end-user is
> > still a client of  LIR but can change to different LIR.
> You are correct.  However, the minimum block size is still /19 or /20 
> depending on the block.  Not /24.  The minimum block sizes still apply in 
> the document I quoted.
I don't think I'm wrong and I think their minimum is even smaller then /24.
Look at this document for example:

They are not making these assignments from LIR's ip blocks, they are making 
it out of separatly situated part of RIR space as I see it.

Now at this point I believe it is necessary for somebody from RIPE to come 
in and clarify the issue as it was done for APNIC.

> And whenever you want to use space you must get permission from RIPE (for 
> each block).  ARIN's fee structure doesn't support that type of service by 
> ARIN, but even if it did I doubt ARIN's members would want to have to go 
> through that level of oversight.
ARIN's fee structure must be changed to accomodate smaller block assignments
and allocations. I'v directly added necessity for new fee schedule in the 
draft of proposal and even said that policy can not be used until new fee 
structure is approved. I also argued that new fee strucuture is necessary 
to accomodate for example micro-allocations and smaller blocks that may 
become as a result of use of 2002-5 and 2002-6 proposals.

> > Upgrade - equipment is cheap these days. Somebody not upgrading and still
> > being in the "stone age" should not be keeping us in the same age! New
> > technologies are being created and if anything ARIN should encorage
> > technological progress and not the other way around.
> So now ARIN's policy proposals are forcing joe end user to upgrade their 
> routers?  If we have that power, then why don't we force people to invest 
> development dollars to make renumbering a piece of cake?  
We're investing in this in development of ipv6 which in fact probably cost 
millions if not billions to companies but have not produced any profit.

> I realize that is a somewhat snide comment, but it was to make a point, 
> that in these tight economic times can we really assume people have dollars 
> to even afford a cheap upgrade?
Down the road road they will have to look into upgrades for many other 
reasons or if they can not afford it what makes you think they should
continue to be multihomed and not just getting default route from their 
upstreams. Being multihomed and getting entire routing table is not 
"cheap" and not everybody can afford it and should do it but for those who 
do we should provide a way to make it worth it with their own ip blocks.

> > So far I have not seen conclusive evidence indicating that multihoming
> > organizations should continue to use their upstream providers's ip blocks.
> > This in itself goes against all purpose of multihoming!
> Well that is one person's opinion.  
That is hardly my own opinion. The person from Worldcom has made the argument
yesterday about how separate network should be tied to ASN and so did 
Stacy Taylor from ICG and she's also on AC and in fact she's been working 
with some others on more standard and more liberal approach to
micro-assignments as successor to 2002-3 and 2002-7. They are also several 
others arguing on the same issue with you all representing this multi-homing

You may not realize it but I'v received emails from people who believe I'm 
too conservative with my proposal and they do not want any ISP involvement
and should be completely free to do what they want and everybody should 
have their own micro-block. I'm actually trying to find middle ground 
between different positions.

> I would _love_ to see more than the 
> handful of people who have been participating in this discussion weigh in. 
> The problem with these mailing lists is that a few people (myself easily 
> included) can monopolize the discussion.
And I hope you do not take it personally, especially since previously you'v
been very fair and argued generally for development of micro-assignment
proposals, but I do think this list is intended for those outside of AC and 
BoT to make their arguments and then AC and BoT should base their decisions
based on arguments presented and not directly on their own opinion.

I do appreciate you making the argument for the other side, but I'd like 
to see somebody else do it too, because otherwise it does seem that my 
side has upper hand which may or may not be the case, though I do think 
(taking ARIN member meetings aside, which are populated by large ISPs) 
the general ARIN community is for multihoming and micro-assignments in 
such a large way that overwhelming majority would have supported previous
2002-3 and 2002-7 proposals if given a chance to vote on it.

One thing to note that point of any debate is not necessarily to win over 
the other side, which is sometimes impossible (and often is not an issue
since good debater can take any position and argue it successfully if 
there is some ground to stand on) but rather to explain the arguments
and supporting documentation in detail which we have done quite well so 
far. It is for larger group that is listening to a debate to decide based 
on presented points which side is more correct.

> Alec, who will do his best to return to lurk mode
I certainly have problems going back to lurk mode and I doubt you can 
either.... Though it would really be at this point to allow others to say 
what they think about arguments that have been presented.

> --
> Alec H. Peterson -- ahp at hilander.com
> Chief Technology Officer
> Catbird Networks, http://www.catbird.com

William Leibzon
Elan Communications 
william at elan.net

More information about the ARIN-PPML mailing list