[ppml] Proposed Policy: IPv4 Micro-allocations for anycast services

[Owen DeLong]

I would expect that each ORG should be limited to a single Anycast block 
until they
can show sufficient service density to justify additional 
allocation/assignment.
For example, if an ORG receives a /24, then, when they have 200+ anycast 
services
deployed, they might be able to justify an additional block.

Not sure how to codify that into policy, but, I think that would address 
your
concerns.

As to the pitfall issues, I think it would be good to put some "Is
Anycast what you really want to do?" information up on the ARIN education 
pages
and refer applicants to them, but, in general, the internet is a loaded 
weapon,
and, like a handgun, requires no special training to purchase.  As such, I 
think
it is not ARINs role to prevent people from shooting themselves in the foot.

Owen

--On August 10, 2005 10:47:47 PM -0400 Leo Bicknell <bicknell at ufp.org> 
wrote:

>
> I like the concept behind this policy, that is to say we shouldn't
> make it hard to deploy anycast services.
>
> My concern though is does the policy as written open up the floodgates
> and/or create loopholes with great abound.  Meeting the requirements
> as listed is not hard.  What happens if people end up not using
> these blocks for anycast services, but rather just as unicast blocks?
> Does the community really want to open up anycast to a wide spectrum
> of people, when the technique is full of pitfalls (for instance,
> TCP applications don't always work so well)?  If someone has multiple
> services out of the same POP's, can each service have any anycast block,
> or only one per company?
>
> I haven't yet formed a full opinion one way or the other, but I do
> think some tigher controls would make me much happer, personally.



-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050810/1306683c/attachment.sig>