[arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks

Wed Jan 17 14:51:11 EST 2018

Owen makes a good point here.

a /40 is quite small, and doesn't leave much room for subnetting.

We should not encourage the practice of giving out less than a /48 per
"site"
or less than a /64 per user.

1 administration domain with 256 locations
2 administration domains with 128 locations each
4 administration domains with 64 locations each
8 administration domains with 32 locations each
16 administration domains with 16 locations each

You would have to correctly guess at the number of
administration domains, and how many location each might have.

And it leaves a lot of IPv6 space on the table when the allocation
size is quite small.

It is a reasonable trade-off that if you want to link up community networks
to a central network you ether need each community network to fork over
$250 for their own /40 (two networks = $500) or get a /36 at $500 and split
the cost.  A /36 split two ways it is a wash.  A /32 at $1,000, split 4 ways
is a wash.

I am comfortable with that approach, if we can document it somewhere.
I'd recommend the comments for this policy (in case anyone looks back)
and in some ARIN FAQ once this policy is adopted.

Lets not confuse the community networks in to thinking that can't just
be an ISP and get ISP space and ISP pricing.

__Jason

On Tue, Jan 16, 2018 at 4:09 PM, Owen DeLong <owen at delong.com> wrote:

> David summarized my views on the matter rather well. I am adamantly
> opposed to trying to make reallocations out of /40 (or longer) prefixes.
>
> Really, a /40 is 256 /48s. Any rational reallocation would be at least a
> /44. Is anyone really in need of running an ISP with only 16 /48s?
>
> I’d rather see any such ISP that is subordinate to a community network (if
> such a construct exists) get their space directly from ARIN under this same
> policy than see us daisy chaining community networks through
> micro-allocations in IPv6.
>
> I’m operating under the assumption that any ISP that has a subordinate ISP
> that isn’t a community network isn’t really a community network, though I
> suppose it might be possible under the proposed rules to engineer such a
> thing if one tried hard enough. Nonetheless, I would argue that such a
> construct is a clear violation of the spirit of the policy even if you
> found a way to do it within the proverbial letter of the law.
>
> Owen
>
> On Jan 16, 2018, at 12:57 , David Farmer <farmer at umn.edu> wrote:
>
> On Tue, Jan 16, 2018 at 11:04 AM, Jason Schiller <jschiller at google.com>
> wrote:
>
>> I support the proposal with the exclusion of section 6.5.9.3.
>> I support the proposal with the inclusion of section 6.5.9.3.
>> I ask what is the purpose of section 6.5.9.3?
>> Is section 6.5.9.3 needed?
>> Is section 6.5.9.3 restricting the right thing?
>>
>> Without section 6.5.9.3 the policy clearly defines a community network,
>> and allows what would otherwise be an LIR  getting a /32 (or /36 upon
>> request)
>> get instead a /40.
>>
>> This would reduce there fees from X-small $1,000 annunally
>> (or upon request 2X-small $500 annually)
>> to 3X-small $250 annually.
>>
>> Sounds well and good.
>>
>>
>> Section 6.5.9.3 adds a further restriction of there shall be no no
>> re-allocations,
>> suggesting they cannot have a user of their space which in turn has its
>> own users.
>>
>> (for the record I think you can drop the text "to other organizations."
>> and just have "However, they shall not reallocate resources.")
>>
>>
>> What behavior are you intending to prevent?
>>
>
> Section 6.5.9.3 has two parts.
>
> The first part says community networks are like other LIRs, they make
> reassignments to end-users and makes it abundantly clear that section 6.5.4
> and 6.5.5 apply to community networks. I don't want anyone arguing that
> those sections don't apply to community networks.
>
> The second part is the restriction on making reallocations. This comes
> back to a couple of arguments; (A.) If community networks can make
> reallocations, then there is no difference between them and a regular
> ISP/LIR, and some participants in earlier discussions were adamant there
> needed to be a difference between community networks and regular ISPs/LIRs.
> (B.) From the debate on ARIN-2013-3: Tiny IPv6 Allocations for ISPs, some
> participants in that discussion were adamant that a /40 was too small of an
> allocation for an ISP, especially if that ISP was to make any
> reallocations.
>
> Doesn't the definition already have the required limits on behavior in the
>> form of:
>>
>> "A community network is deployed, operated, and governed by its users,
>> for the purpose of providing free or low-cost connectivity to the
>> community it services."
>>
>> It appears what you are preventing are the cases below.  I ask is this
>> what you
>> intend to prevent?  and if so why?
>>
>> Should the Colorado IPv6 cooperative be prevented from providing transit
>> to the
>> Rocky Mountain Spotted IPv6 community network because they in turn assign
>> IPv6 addresses to community members?
>>
>>
>> What if this is all within one community network?  What if the Rocky
>> Mountain
>> Spotted IPv6 community network has a part of the network that is managed
>> by
>> a group in Ball Mountain community and another part is managed by a group
>> in
>> Mount Lincoln.  Wouldn't it make sense to re-allocate some of the Rocky
>> Mountain
>> Spotted IPv6 community network's /40 to Ball Mountain community and let
>> them
>> handle the assignments to users in their locale?
>>
>
> Personly, I'd be fine with removing the restriction on community networks
> making reallocations, but I'd still want to have section 6.5.9.3 I'd
> rewrite is as follows;
>
> *6.5.9.3. Reassignments by Community Networks*
>
> *Similar to other LIRs, Community Networks shall make reassignments and
> reallocations in accordance with applicable policies, in particular, but
> not limited to sections 6.5.4 and 6.5.5. *
>
> What do others think should community networks be allowed to make
> both reassignments and reallocations, or just reassignments?
>
> Thanks.
>
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE
> <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g>
>       Phone: 612-626-0815 <(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
> ===============================================
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>

-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180117/0b982181/attachment.htm>