Re: [address-policy-wg] Proposal for change to the IPv4 PI allocation policy

[Max Tulyev president@localhost]

Hi!

Dmitry Kiselev wrote:
> Hello!
>
> On Mon, Aug 21, 2006 at 02:31:38PM +0200, Mikael Abrahamsson wrote:
>
>   
>> Hello.
>>
>> Following a discussion between some people and the resulting request to
>> bring the discussion here I would like to propose a change to allocation 
>> policy for small PI blocks.
>>
>> Today it's a problem that the ISP industry BCP involves filtering all 
>> announcements smaller than /24 from BGP, this meaning that a smaller 
>> allocation from RIPE is pretty much unusual in the "real world" if you 
>> want to be on the public internet.
>>
>> I would therefore like to see a discussion about making it an option to 
>> actually get a /24 for routing reasons, disregarding current policy of 
>> disallowing routing problems as justification to request an allocation 
>> bigger than you might be able to justify from address usage alone.
>>
>> I know I ran into this problem when I first started in the ISP business 
>> around 1995, and it's still there, so might it be time to change? People 
>> with enough experience will creatively "enhance" (ie lie) address requests 
>> to actually reach the /24 size today, and people without experience will 
>> make an honest request and then run into practical problems with their 
>> newly allocated space when they want to use it in real life, due to it 
>> being filtered because it's too small according to industry BCP. This is 
>> of course a bad situation either way and I hope it can be rectified.
>>
>> Thanks for your attention.
>>     
>
>
> Do You mean PI *ASSIGNMENT*? According to ripe-368, no new PI allocations
> are allowed.
>
>   
Yes, it seems to be about assignments.

As many persons like to write in blogs and forums - "+1" from me ;)
It is a good idea to set formalities as close to real life as possible,
and also prevent unexperienced people from troubles.
Another good idea is to remove user scaring story about PI is worse
routeable than PA from RIPE documents.

-- 
WBR,
Max Tulyev (MT6561-RIPE, 2:463/253@localhost)