[ppml] Policy Proposal: SWIP support for smaller than /29

Hey Mack,

mack wrote:
> I am not certain this policy is necessary.  Expanding SWIP by a factor of 8
> may put an undue burden on the infrastructure.

Whether the policy is neccessary and whether infrastructure can support 
potential larger demand are seperate questions.

I believe the policy change is beneficial. In the hard to credit 
scenario where every single /29 SWIP record turned into 2 /30 or 4 
/32's, that could be taken as ample evidence that the policy change was 
very much required, based on subsequent usage demands.

Resource limits, should that be a concern, could also be better handled 
by imposing a cap of SWIP records per allocation.

In any event, I view it as extremely unlikely to occur.

At some point (usually well before an organization would want to manage 
thousands of SWIP records through ARIN) rwhois would be the natural choice.

> 
> SWIP for blocks smaller than /29 moves the burden of maintenance to ARIN.

I dont see how they would view it much differently than an organization 
that just never did any assignations smaller than /29.

I suspect that ARIN would actually find it much easier to process 
justification where ALL data was in one place, be it SWIP or RWHOIS, 
than a combination of either plus tables.

> 
> Although I agree with the objection that RWHOIS is ancient, until someone
> develops something better we are going to see increasing use.  The RWHOIS
> distributed model seems better suited for long term use than SWIPs centralized
> model.  Particularly as the amount of data expands to 3 billion+ records.

The hosts file is also ancient. Yet all systems ship with it. Age is not 
in and of itself an issue.

A centralized SWIP can be depoyed in a decentralized manner internaly.

Are there any statistics as to actual records in ARIN SWIP and how many 
they could expect to reasonably support?

In any event, it is highly unlikely that allowing the smaller records 
would equate into the expansion you are contemplating. /29 records wont 
immediately be turned into 4 /32 records.

The real performance question is likely the time taken to arrive at no 
match for queries. /32 as opposed to /29 could increase that time 
depending on implementation.

> 
> RWHOIS and the table format already provide the capability to display blocks
> smaller than a /29.

And that SWIP doesnt, should either be justified by resource constraints 
or rectified.

> 
> I don't have evidence but I believe ARIN staff already take RWHOIS into
> account if blocks smaller than /29 are displayed.

Either RWHOIS is used for an allocation or it is not. If seperately sub 
/29 allocations are listed, ARIN calls for the table format to be used.

I suppose ARIN will consider whatever data you supply.

> 
> This proposal could be considerably simplified by only retaining the following
> modification:
> 
> 
>>4.2.3.7.5.) Accounting for additional utilization
>>
>>"
>>The following format should be used to provide the required information
>>for utilization of blocks smaller than /29 and for describing internal
>>networks:
>>"
>>
>>Replace with
>>
>>"
>>The following format should be used to provide the required information
>>for utilization of blocks smaller than /29 and for describing internal
>>networks when either SWIP or RWHOIS server is not used:
>>"
> 
> 
> This implies ARIN will accept SWIP of blocks smaller than /29 and get data
> from either SWIP or RWHOIS before requiring the tabular format.
> 
> Or the alternative format proposed, which is neutral on method:
> 
> 
>>4.2.3.7.5.) Accounting for additional utilization
>>
>>"
>>The following format should be used to provide the required information
>>for utilization of blocks smaller than /29 and for describing internal
>>networks:
>>"
>>
>>Replace with
>>
>>"
>>For blocks smaller than /29 and for internal space, ISPs must provide
>>utilization data via one of the following methods: SWIP, RWHOIS server,
>>or the following table format:
>>"
> 

The semantics are secondary to the objective in this instance.

> 
> For the record I think ARIN should accept data in the three formats
> provided but SWIP does not seem scalable into the future.

I suspect that SWIP is as scalable as RWHOIS, since under the hood they 
can be implemented the same way.


Joe


> 
> --
> LR Mack McBride
> Network Administrator
> Alpha Red, Inc.