[ppml] Draft 2 of proposal for ip assignment with sponsorship
Alec H. Peterson
ahp at hilander.com
Fri Feb 28 09:52:40 EST 2003
--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
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):
> 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.
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
More information about the ARIN-PPML