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

[Alec H. Peterson]

--On Friday, February 28, 2003 4:40 AM -0800 william at elan.net wrote:

>
> Are you so sure summarization is such a good thing? Multihoming is the
> way to  allow multiple routes to a network and to allow network to be up
> through  backup provider when primary one is down. Now you summarize the
> routes  and primary provider of some organization is down  (assuming
> primary is  the one who has that /14 and company is using /22 out of
> that) because  you summarized the routes you would not be able to reach
> 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?

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

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

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.

> 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?  Large service 
providers have done it, so clearly it is possible.

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?

>
> And just on this point, the proposal would not increase size of routing
> table at least not to those who do not do summarization and for others
> not right away in any considerable amount giving them enough time (i.e.
> probably 2-5 years) to upgrade and take advantage of new router hardware
> that will be needed anyway if they want to speak ipv6 in the future.

Y2K.

People will run the same old hardware and software for decades.


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

So other people, __PLEASE__ put in your two cents.  I am quite sure there 
are more than a half dozen people with a stake in this discussion.

For my part, I've presented what I see as an under-represented side of the 
argument.  For what it's worth I agree that being tied to one's ISP by IP 
space is a Bad Thing[tm], though I do maintain that setting up good 
procedures with one's customers and in one's systems can minimize the 
impact of that.  I probably won't participate much any more so that other 
people can weigh in, since as an AC member what I really hope to get out of 
these discussions is what the community thinks (so far I and the rest of 
the AC only know what a few people think).

I know everybody hates 'Me Too' posts, but in this instance (where we are 
trying to gauge some sort of concensus) it would actually be helpful 
(though perhaps a few sentences describing exactly what you think relating 
to these topics).

Alec, who will do his best to return to lurk mode

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