[arin-ppml] Multihomed Microallocations

[Kevin Kargel]

> 
> Why does the small user and experimenter WANT PI space in the first
> place?  Well, their multihoming I hear you say.  Baloney.  You do not
> need PI space to multihome.  You can advertise an assignment from an
> upstream just fine.  So what that there's a covering route out there,
> you still have your redundancy.

Gee, last week when I suggested doing it that way people jumped all over me
telling me how that was broken and next to worthless..  I do agree with them
to a large degree based on what happens if I give IP space to a multi-home
customer, announce his network and the aggregate, another ISP announces only
the small network, and then my connection to the customer goes down.  

The only way (to my understanding and as I was told last week) to get a
fully functional redundancy model without LOTS of silly router tricks is for
the customer to have their own ASN.  When they have their own ASN I could
de-aggregate what I allocate to them, but once they have their own ASN
anyway then the 'might as well have their own netblock' comes in to play. 

> 
> When you boil it down it really comes to 2 reasons:
> 
> a) The small operator wants to be able to tell an upstream to kiss
> off if they get pissy with him, without renumbering.  That's lock-in.

This is not trivial.  Allowing provider independence is a good thing. I
enjoy it and I expect others do also. 
If we are trying to write ARIN policy to support an addictive business plan
I would call that a conflict of interest which should be vigorously avoided.


> 
> b) The small operator cannot get even a small amount of space (like
> a /24) from an upstream because that upstream is severely constrained on
> IP.

While I don't think that is typically the case now, I suspect it is
possible, and in the future will be likely.

c) They are interested, they want to educate themselves, experiment and do
it like the big people.  This is ok in my book and qualifies as a
justification.  Remember that there are costs and red tape hurdles to go
through that will limit this type of exercise.  Everybody has to start some
where, and this looks like a good starting point to me.  

> 
> 
> Neither reason is really valid now.  Renumbering a /24 is childs play,
> if an "experimenter" or "small user" cannot manage to renumber a /24
> they are incompetent and shouldn't be fooling around in this to begin
> with.  So what it's inconvenient - their desire for less inconvenience
> is at the expense of the entire Internet.  Thus, for a /24, lock-in is
> a myth.
> 
> As for the upstream being constrained, well I don't see ARIN denying
> IPv4 requests right now.  Sure they will in the future - but there will
> be plenty of small /24's that are currently abandoned that ARIN will end
> up taking back as a result of recovery efforts.  If an upstream is
> claiming they are IP constrained that is a flat out lie.  Send them to
> the RIR for more numbering.
> 
> Now, maybe in the future this will change and little allocations won't
> be available anymore.  So people are wanting to get their
> microallocations now, before the land rush.  OK, fine, no problem there.
>   But eventually no matter what policy is done, there won't be any
> more allocations of any kind.
> 
> You might be throwing a lifeline to the small users and experimenters
> right now, but only for the next few years crop of 'em.  After all,
> what do you think becomes of experimenters when their IPv4 disappears?
> Those that have brains and courage come out all right; those that
> haven't are winnowed out.

Well, if policy for the remainder of IPv4 life is only the next few years
and doesn't matter then we should all save ourselves a bunch of work and
quit wasting our time discussing IPv4 policy.  I don't buy this line of
thinking.

I really don't see this becoming a big burden on the backbone, and I see no
need to slam the door on the few that may want to do it and will be willing
to pay for it.

Kevin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090804/2890e2f1/attachment.bin>