This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8)
- Previous message (by thread): [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8)
- Next message (by thread): [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Benson Schliesser
bensons at queuefull.net
Fri Jul 9 18:16:09 CEST 2010
On 8 Jul 10, at 9:42 PM, Randy Bush wrote: > >> It *will* run out, no matter what we do - the only question remaining >> is "will we able to lessen the pain (especially for future entrants >> into this arena) a bit with this policy, or not". > > for a long while, we have used conserving routing table space to place a > barrier to entry to the market. this proposal removes that for future > entrants who need a teensie bit of v4 to front to the legacy v4 part of > the dual stack network. As implied, this proposal enables future entrants at the expense of routing table conservation. To what extent should the RIR community be concerned about enabling access / competition, versus the ongoing operation of existing networks? Whether we're discussing an IPv4 market or the market for transitionary network services, there are organizations prepared to facilitate new entrants. A "chop it in small pieces" policy would not extend the life of IPv4 indefinitely; we will run out, and these markets will be the only option. Until then, these markets would be artificially devalued. Further, this policy may lead to wasted IPv4 resources if new organizations do not emerge to consume the remaining space. Existing networks may struggle due to inadequate IPv4 resources, while the reserved pool sits unclaimed. The worst case is where all of the above exists together: wasted IPv4 resources in an unclaimed pool, devalued transitionary markets, and network providers unable to grow their services while facing the operational impact of a growing routing table. I would feel much better about this policy if it allowed for subsequent /22 assignments over time. Perhaps a limit of 1 assignment per 90 days, or something along those lines. -Benson
- Previous message (by thread): [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8)
- Next message (by thread): [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]