About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section

Re: [address-policy-wg] 2007-08 New Draft Document Published (Enabling Methods for Reallocation of IPv4 Resources)

  • To: Eliot Lear lear@localhost
  • From: Nigel Titley nigel@localhost
  • Date: Fri, 10 Oct 2008 11:01:05 +0100

Eliot Lear wrote:
Nigel,

V3 of the policy was explicitly issued to address the main ETNO concern, that is the "need" requirement. If you carefully look at V3 you will see that the RIPE NCC now has to apply exactly the same checking and approval process that it does for a "normal" allocation.

This brings 2007-08 closer to ARIN's 2008-2, and in fact "improves" on it by not prohibiting disaggregation. While you very reasonably point out that the routing table could explode under such circumstances, having such a prohibition along with needs justification can lead to perverse impacts where holders of large blocks are only able to unload them to large users like ISPs.

Are there additional mechanisms that could be put into play to limit that explosion? For instance, could one cap the deaggregation rate per aggregated block to some number per anum? What work has been done in this area.
If you look closely at 2007-08 you will see that the minimum size of block that can be transferred is the minimal size of block that RIPE NCC can currently allocate. This allows the deaggregation of larger blocks, but also puts a cap on the amount of deaggregation that can occur.

Nigel



 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community