[address-policy-wg] Idea for aggregating IP addresses

Hi,

but the receiving party could (will?) announce more specific prefixes 
after the trade, therefore it wont make a big difference after all.

Jörg

On 23 Sep 2016, at 9:10, Ping IP wrote:

> Hello Jörg,
>
> Although I used a /22 and /20 as an example. I deliberately mention IP
> addresses, since this idea can be used for IPv4 and IPv6.
>
> Perhaps its too little, too late for IPv4. But it helps one of the 
> goals of
> RIPE.
>
> Best regards,
>
> Abdelouahed
> Ping IP network
>
> 2016-09-22 16:04 GMT+02:00 Jörg Kost 
> <joerg.kost at premium-datacenter.de>:
>
>> Hi,
>>
>> I like the idealism of this idea, but it is too little, too late and 
>> much
>> too many work to save a few bytes on the ip4 routing table. This race 
>> is
>> lost, adding more memory to the board or block and remove certain 
>> routes
>> will be the solution. My focus shifted already to the future (?)
>> disaggregation of ip6, where we had hit the 32k lately.
>>
>> Jörg
>>
>>
>> On 22 Sep 2016, at 14:37, Ping IP wrote:
>>
>> Hello,
>>>
>>> One of the goals of RIPE is to aggregate IP addresses. I'd like to 
>>> suggest
>>> the ability for a LIR and End User to exchange number of blocks of 
>>> IP
>>> ranges for a greater block.
>>>
>>> For example:
>>> LIR/End User has 4 different /22 subnets and LIR/End User can 
>>> exchange
>>> these subnets for 1 x /20 subnet.
>>>
>>> This gives a LIR or End User the possibility to announce larger IP 
>>> subnets
>>> to the Internet. Helping the goal of aggregating the IP addresses on 
>>> the
>>> Internet.
>>>
>>> According one of the RIPE trainer, this is currently not possible
>>> according
>>> the RIPE policy. Because there's no policy to give a LIR/End User 
>>> this
>>> ability.
>>>
>>> I'm curious to what you think of this idea.
>>>
>>> Best regards,
>>>
>>> Abdelouahed
>>> Ping IP network
>>>
>>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20160923/38058b0f/attachment.html>