You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.1

Address Policy Working Group

Threaded
Collapse

[address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs)

User Image

Marco Schmidt

2019-10-15 14:43:10 CET

RIPE NCC staff member

Dear colleagues,

A new RIPE Policy proposal, 2019-07, "Default assignment size for IXPs"
is now available for discussion.

This proposal aims to change the default IXP assignment size from a /24
to a needs-based model, with a /27 as a minimum.

You can find the full proposal at:

https://www.ripe.net/participate/policies/proposals/2019-07

As per the RIPE Policy Development Process (PDP), the purpose of this
four week Discussion Phase is to discuss the proposal and provide
feedback to the proposer.

At the end of the Discussion Phase, the proposer, with the agreement of
the WG Chairs, will decide how to proceed with the proposal.

We encourage you to review this proposal and send your comments to
<address-policy-wg _at_ ripe _dot_ net> before 13 November 2019.

Regards,

Marco Schmidt
Policy Officer
RIPE NCC


User Image

James Blessing

2019-10-15 15:24:30 CET

On Tue, 15 Oct 2019, 13:43 Marco Schmidt, <mschmidt _at_ ripe _dot_ net> wrote:

> Dear colleagues,
>
>
> This proposal aims to change the default IXP assignment size from a /24
> to a needs-based model, with a /27 as a minimum.
> L


Whilst I support the goal of the proposal the current wording doesn't parse
particularly well.

By changing 'once' to 'if' and then referencing returned addresses it
(possibly) creates a confusion.

I would go with...

New IXPs will be assigned a /27 as a minimum. If an IXP requires a larger
assignment, they must demonstrate need for at least 50% of the new
assignment within two years. A maximum assignment of a /22 is available for
a suitablly qualified IXP. Any existing addresses (such as PI) used for an
IXP peering LAN shall be returned.

Feel free to butcher the text further, but I hope I've explained the reason
for the change in the change itself

Thx
User Image

Tore Anderson

2019-10-15 16:26:51 CET

* Marco Schmidt

> A new RIPE Policy proposal, 2019-07, "Default assignment size for IXPs"
> is now available for discussion.
> 
> This proposal aims to change the default IXP assignment size from a /24
> to a needs-based model, with a /27 as a minimum.

While I do support the proposal's aim of reducing the default assignment size, I would suggest that we make the default a /29 instead of a /27:

- The reserved IXP pool currently contains prefixes sized /29 and /28. These can not be delegated under neither the current nor the proposed policy. However, small IXPs could make use of these just fine. I see why reason why we should «lock them up and throw away the key».

- Looking at figure 2 at https://github.com/mwichtlh/address-policy-wg/ it would appear that ~43% of all IXPs would fit into a /28 including 100% overprovisioning (or into a /29 with no overprovisioning). This suggests that /29s and /28s would be useful and sufficient to a significant number of IXPs.

- Lowering the default assignment size to a /29 does obviously not mean that IXPs that do require a /27 or larger should not receive it. They simply have to justify it, exactly the same as an IXP requesting a /{26..22} would have to under the proposed policy. This is not a unreasonable thing to ask, in my opinion - IPv4 is a very scarce resource, after all.

- This might require growing IXPs to renumber from /29->/28->/27, which they would not have to do under the currently proposed policy. However, I do not think that is an unreasonable thing to ask. The smaller the IXP is, the easier it is to coordinate a renumbering process. Renumbering is in any case a process they will to go through as they grow out of the /27 currently proposed as the new default assignment size.

Tore

Nick Hilliard

2019-10-22 18:24:18 CET

Marco Schmidt wrote on 15/10/2019 13:43:
> This proposal aims to change the default IXP assignment size from a /24
> to a needs-based model, with a /27 as a minimum.

This proposal doesn't seem well-thought-out.

The first, and main, issue is that renumbering IXPs is a terrible 
headache and is something that should be avoided if possible.

The sorts of problems that regularly erupt would include:

- loss of service during renumbering, with traffic being forced over 
backup paths at times that may not suit

- ixp participants being forced to undergo network changes outside their 
normal maintenance window procedures (some networks cannot do this).

- problems with IXP prefix misorigination due to filters not being 
updated properly, which can cause loss of service problems.

- other larger-scale configuration issues due to people making 
substantial config changes to their peering routers, which usually takes 
some time to iron out the bugs.  I.e. this is not as simple as a global 
search + replace.

INEX was a good internet citizen and started out with a /27 on our main 
peering LAN in 1996.  When that ran out, we moved to a /26 and then a 
/25.  We're now at /23.  For each renumbering operation, we ran into the 
problems above, and a lot more.  So from multiple experience, I wouldn't 
wish it on anyone to have to go through an IXP renumbering without good 
reason.  It really is a thorough pain, especially for the IXP participants.

The second issue is that there are ~220 IXPs operating in the countries 
in the ripe ncc region.  This number is pulled from IXPDB 
(https://api.ixpdb.net/v1/provider/list), and cross-referenced against 
the list of RIPE NCC countries here:

https://www.ripe.net/participate/member-support/list-of-members/list-of-country-codes-and-rirs

A /15 has enough space for 512x/24 blocks, which means that this block 
will probably last indefinitely if the minimum assignment size is /24.

By reducing this to /27, all that's going to happen is that IXPs and 
their participants will be dragged through unnecessary renumbering 
procedures; but it is unlikely to make the block last longer.

I'd like to respectfully suggest that the proposal be dropped.

Nick

Martin Pels

2019-10-24 10:23:51 CET

Hello,

On 22/10/19 18:24, Nick Hilliard wrote:
> INEX was a good internet citizen and started out with a /27 on our main
> peering LAN in 1996.  When that ran out, we moved to a /26 and then a
> /25.  We're now at /23.  For each renumbering operation, we ran into the
> problems above, and a lot more.  So from multiple experience, I wouldn't
> wish it on anyone to have to go through an IXP renumbering without good
> reason.  It really is a thorough pain, especially for the IXP participants.

Having gone through a renumbering exercise for an IXP myself (/22 to
/21) I can confirm that this is a painful process. But it is certainly
not an insurmountable challenge. Also, the smaller the IXP, the easier
it is. Fewer participants means less coordination.

The proposal already accommodates two years worth of growth, so it is
not like a renumbering exercise would be needed very often.

> The second issue is that there are ~220 IXPs operating in the countries
> in the ripe ncc region.  This number is pulled from IXPDB
> (https://api.ixpdb.net/v1/provider/list), and cross-referenced against
> the list of RIPE NCC countries here:
> 
> https://www.ripe.net/participate/member-support/list-of-members/list-of-country-codes-and-rirs
> 
> 
> A /15 has enough space for 512x/24 blocks, which means that this block
> will probably last indefinitely if the minimum assignment size is /24.

Possibly. But there is no guarantee that the growth in the number of
IXPs will remain the same. So being a bit conservative when there is
little downside seems wise to me.

I agree with James that the wording could be made a bit clearer.
Furthermore I think it should at least be possible to assign a /28 or a
/29 if an IXP requests this or if there are no larger blocks available.
But I don't think there's anything wrong with the /27 default, so I
support the proposed change in general.

Kind regards,
Martin

User Image

Tore Anderson

2019-10-25 06:51:29 CET

* Martin Pels

> On 22/10/19 18:24, Nick Hilliard wrote:
>> INEX was a good internet citizen and started out with a /27 on our main
>> peering LAN in 1996.  When that ran out, we moved to a /26 and then a
>> /25.  We're now at /23.  For each renumbering operation, we ran into the
>> problems above, and a lot more.  So from multiple experience, I wouldn't
>> wish it on anyone to have to go through an IXP renumbering without good
>> reason.  It really is a thorough pain, especially for the IXP participants.
> 
> Having gone through a renumbering exercise for an IXP myself (/22 to
> /21) I can confirm that this is a painful process. But it is certainly
> not an insurmountable challenge.Also, the smaller the IXP, the easier
> it is. Fewer participants means less coordination.

Precisely.

Renumbering is annoying for everyone, but it is an necessary inconvenience in order to deal with IPv4 being in short supply. This is not an IXP specific consideration - I renumber server LANs with public IPv4 regularly, for example. It is definitively not fun, but it necessary to preserve my LIR's IPv4 pool.

Besides, by renumbering while the IXP is still small, valuable experience is gained.

In the case described by Nick, if INEX had started out with a /24 (per current policy), a renumbering operation would still have had to happen to go to the current /23. In other words, the largest and most difficult renumbering exercise would have had to be performed with zero prior experience.

I am not convinced that would be a better situation to find oneself in than having previously renumbered every five years or so (on average).

> The proposal already accommodates two years worth of growth, so it is
> not like a renumbering exercise would be needed very often.

Indeed, although it is actually *four* years, not two (assuming linear growth).

>> A /15 has enough space for 512x/24 blocks, which means that this block
>> will probably last indefinitely if the minimum assignment size is /24.
> 
> Possibly. But there is no guarantee that the growth in the number of
> IXPs will remain the same. So being a bit conservative when there is
> little downside seems wise to me.

Personally I take any claim that that an IPv4 resource will last indefinitely with a healthy dose of scepticism.

It took the IXP community eight years to go from «a /16 will do» (2011-05) to «um, on second thought, make that a /15» (2019-05).

There will be no third serving, so I agree fully that we should be conservative.

> I agree with James that the wording could be made a bit clearer.
> Furthermore I think it should at least be possible to assign a /28 or a
> /29 if an IXP requests this or if there are no larger blocks available.
> But I don't think there's anything wrong with the /27 default, so I
> support the proposed change in general.

Agreed on /29 - the IXP pool does contain /28 and /29 prefixes, so it is glaringly inconsistent that current policy disallows their assignment.

However, once you accept that the minimum should be /29, then setting the default to /27 seems rather arbitrary. There's nothing special about /27 that makes it an obvious default value.

I believe the logical thing to do is to put the default at the /29 as well. Having the default equal to the minimum is the most conservative and thus the best suited for making the IXP pool last "forever".

Of course, that does not mean that an IXP will not get a larger assignment if it needs it. To qualify for an initial /27, for example, the IXP would only need to have 14 connections total (members, RSes, etc.) within two years of assignment. This is sufficiently accommodating for new IXPs, in my opinion.

Tore

User Image

Arash Naderpour

2019-10-25 08:08:06 CET

Hi,

Do we know how many /29 we have available in the IXP reserved pool? if
there are only few ones, it doesn't make scene to me set the default to /29
as it would be a good practice for just few allocations.

Can someone from RIPE NCC provide us with an statistic on number of
different prefixes in the IXP pool?

Regards,

Arash
>I believe the logical thing to do is to put the default at the /29 as
well. Having the default equal to the minimum is the most conservative and
thus the best suited for making the IXP pool last "forever".
User Image

Carlos Friacas

2019-10-25 08:24:30 CET

Greetings,

/27 as default seems a sensible approach.

While exponential growth is something that most IXPs would like to see, 
the reality is that it doesn't happen everywhere.

Thus, I support 2019-07.

Regards,
Carlos



On Fri, 25 Oct 2019, Tore Anderson wrote:

> * Martin Pels
>
>> On 22/10/19 18:24, Nick Hilliard wrote:
>>> INEX was a good internet citizen and started out with a /27 on our main
>>> peering LAN in 1996.  When that ran out, we moved to a /26 and then a
>>> /25.  We're now at /23.  For each renumbering operation, we ran into the
>>> problems above, and a lot more.  So from multiple experience, I wouldn't
>>> wish it on anyone to have to go through an IXP renumbering without good
>>> reason.  It really is a thorough pain, especially for the IXP participants.
>>
>> Having gone through a renumbering exercise for an IXP myself (/22 to
>> /21) I can confirm that this is a painful process. But it is certainly
>> not an insurmountable challenge.Also, the smaller the IXP, the easier
>> it is. Fewer participants means less coordination.
>
> Precisely.
>
> Renumbering is annoying for everyone, but it is an necessary inconvenience in order to deal with IPv4 being in short supply. This is not an IXP specific consideration - I renumber server LANs with public IPv4 regularly, for example. It is definitively not fun, but it necessary to preserve my LIR's IPv4 pool.
>
> Besides, by renumbering while the IXP is still small, valuable experience is gained.
>
> In the case described by Nick, if INEX had started out with a /24 (per current policy), a renumbering operation would still have had to happen to go to the current /23. In other words, the largest and most difficult renumbering exercise would have had to be performed with zero prior experience.
>
> I am not convinced that would be a better situation to find oneself in than having previously renumbered every five years or so (on average).
>
>> The proposal already accommodates two years worth of growth, so it is
>> not like a renumbering exercise would be needed very often.
>
> Indeed, although it is actually *four* years, not two (assuming linear growth).
>
>>> A /15 has enough space for 512x/24 blocks, which means that this block
>>> will probably last indefinitely if the minimum assignment size is /24.
>>
>> Possibly. But there is no guarantee that the growth in the number of
>> IXPs will remain the same. So being a bit conservative when there is
>> little downside seems wise to me.
>
> Personally I take any claim that that an IPv4 resource will last indefinitely with a healthy dose of scepticism.
>
> It took the IXP community eight years to go from «a /16 will do» (2011-05) to «um, on second thought, make that a /15» (2019-05).
>
> There will be no third serving, so I agree fully that we should be conservative.
>
>> I agree with James that the wording could be made a bit clearer.
>> Furthermore I think it should at least be possible to assign a /28 or a
>> /29 if an IXP requests this or if there are no larger blocks available.
>> But I don't think there's anything wrong with the /27 default, so I
>> support the proposed change in general.
>
> Agreed on /29 - the IXP pool does contain /28 and /29 prefixes, so it is glaringly inconsistent that current policy disallows their assignment.
>
> However, once you accept that the minimum should be /29, then setting the default to /27 seems rather arbitrary. There's nothing special about /27 that makes it an obvious default value.
>
> I believe the logical thing to do is to put the default at the /29 as well. Having the default equal to the minimum is the most conservative and thus the best suited for making the IXP pool last "forever".
>
> Of course, that does not mean that an IXP will not get a larger assignment if it needs it. To qualify for an initial /27, for example, the IXP would only need to have 14 connections total (members, RSes, etc.) within two years of assignment. This is sufficiently accommodating for new IXPs, in my opinion.
>
> Tore
>
User Image

Tore Anderson

2019-10-25 08:30:21 CET

* Arash Naderpour

> Do we know how many /29 we have available in the IXP reserved pool? if there are only few ones, it doesn't make scene to me set the default to /29 as it would be a good practice for just few allocations.
> 
> Can someone from RIPE NCC provide us with an statistic on number of different prefixes in the IXP pool?

Hi Arash,

While I'm not from the NCC, below is the complete list of blocks smaller than /24 currently found in the IXP pool (or could be in quarantine, but destined for the IXP pool nevertheless).

I spot at least four /29s in it (193.58.0.48/29, 193.188.134.136/29, 193.188.134.200/29, 194.180.226.144/29).

An additional 13 /29s are currently assigned; if returned, these will also be added to the IXP pool under current policy.

Tore

$ curl -s ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest | awk '-F|' '$3 == "ipv4" && $5 < 256 && $7 == "reserved"'
ripencc||ipv4|193.34.193.128|128||reserved
ripencc||ipv4|193.34.196.128|128||reserved
ripencc||ipv4|193.34.199.128|128||reserved
ripencc||ipv4|193.34.201.128|128||reserved
ripencc||ipv4|193.58.0.48|8||reserved
ripencc||ipv4|193.164.232.96|64||reserved
ripencc||ipv4|193.164.232.224|32||reserved
ripencc||ipv4|193.188.134.136|8||reserved
ripencc||ipv4|193.188.134.200|56||reserved
ripencc||ipv4|193.192.12.0|128||reserved
ripencc||ipv4|193.201.145.128|128||reserved
ripencc||ipv4|193.201.147.192|32||reserved
ripencc||ipv4|193.201.148.128|64||reserved
ripencc||ipv4|193.201.149.0|64||reserved
ripencc||ipv4|193.201.149.128|64||reserved
ripencc||ipv4|193.201.150.192|64||reserved
ripencc||ipv4|193.201.151.64|128||reserved
ripencc||ipv4|193.201.155.0|128||reserved
ripencc||ipv4|193.201.157.128|128||reserved
ripencc||ipv4|193.201.159.0|128||reserved
ripencc||ipv4|193.218.207.64|16||reserved
ripencc||ipv4|193.243.183.0|64||reserved
ripencc||ipv4|193.243.183.128|64||reserved
ripencc||ipv4|194.42.47.0|128||reserved
ripencc||ipv4|194.93.123.0|128||reserved
ripencc||ipv4|194.117.50.0|128||reserved
ripencc||ipv4|194.117.55.0|128||reserved
ripencc||ipv4|194.153.153.0|128||reserved
ripencc||ipv4|194.153.157.0|128||reserved
ripencc||ipv4|194.153.158.0|128||reserved
ripencc||ipv4|194.153.159.128|128||reserved
ripencc||ipv4|194.180.159.0|240||reserved
ripencc||ipv4|194.180.226.0|152||reserved
ripencc||ipv4|194.180.226.160|96||reserved
ripencc||ipv4|194.246.39.0|96||reserved
ripencc||ipv4|194.246.39.192|32||reserved
ripencc||ipv4|195.13.37.128|128||reserved
ripencc||ipv4|195.35.104.0|32||reserved
ripencc||ipv4|195.60.80.0|96||reserved
ripencc||ipv4|195.60.81.128|64||reserved
ripencc||ipv4|195.60.83.32|32||reserved
ripencc||ipv4|195.60.83.128|32||reserved
ripencc||ipv4|195.60.84.128|128||reserved
ripencc||ipv4|195.60.85.128|128||reserved
ripencc||ipv4|195.60.88.0|128||reserved
ripencc||ipv4|195.60.91.128|128||reserved
ripencc||ipv4|195.60.92.192|64||reserved
ripencc||ipv4|195.60.93.64|64||reserved
ripencc||ipv4|195.60.94.128|128||reserved

User Image

Andy Davidson

2019-10-25 12:54:32 CET

Dear colleagues,

On 22/10/2019, 17:24, Nick Hilliard <nick _at_ foobar _dot_ org> wrote:
> Marco Schmidt wrote on 15/10/2019 13:43:
> > This proposal aims to change the default IXP assignment size from a /24
> > to a needs-based model, with a /27 as a minimum.
>  This proposal doesn't seem well-thought-out.
[...]

I strongly oppose the 2019-07 policy proposal for the reasons expressed by Nick Hilliard.  

I think an IXP operator should be able to request a longer prefix than a /24 in the IXP Assignment policy but the default assignment size should not change from a /24.

IXPs need to operate on the principle of least surprise, especially as the experience and the expertise of networks connecting continues to expand beyond the traditional boundaries.

Best wishes,
Andy Davidson

Radu-Adrian FEURDEAN

2019-11-13 14:41:46 CET

Hello,

On Tue, Oct 15, 2019, at 14:43, Marco Schmidt wrote:
> Dear colleagues,
> 
> A new RIPE Policy proposal, 2019-07, "Default assignment size for IXPs"
> is now available for discussion.

A little late, but here's my point of view:
 - /27 is borderline for a default. Hopefully the 50% use within 2 years should alleviate this (even if I find it not enough).
 - Anything smaller than a /27 is close to useless.
 - Renumbering is painful and should be avoided as much as possible. 
 - IXP growth may be very variable in time. You may struggle for 1-2 years, then add several dozens members the next year. You may easy get in a situation when renumbering falls in a period of rapid growth, which only makes things worse.

The peering landscape has changed quite a lot during the last years. You have to deal with NOCs that function purely "by the book", usually a book not well written. You have to deal with lack of coordination between operations and strategy. You have to deal more and more with "the peering coordinator changed, there is no more peering policy". You have to deal with "there might be a slight impact, we need a change request approved, it will take 3 months at least". This noes not touch only the small participants, this does touch *EVERYONE*. At the end, you end up with x% (where x>10, even x>20) of your user base does not respond in a timely manner (if at all). Because of this you will end up looking as "not serious" (sometimes by the same people that took 3 months to do the renumbering).

My suggestion :
 - if the default assignment size is to be lowered, that should be a /25 or a /26, not smaller.
 - The "target use" (currently "50% within 2 years"), should be a little more relaxed (either 3 years, or something like 35%-40% use within 2 years). 

I wouldn't mind reserving space for future enlargement (with reservations being re-allocated or reduced when space is needed by other members), but I think wording for that would render the policy way too complex.

-- 
Radu-Adrian FEURDEAN

Scott Leibrand

2019-11-13 15:04:27 CET

> On Nov 13, 2019, at 5:43 AM, Radu-Adrian FEURDEAN <ripe-wgs _at_ radu-adrian.feurdean _dot_ net> wrote:
> 
> Hello,
> 
>> On Tue, Oct 15, 2019, at 14:43, Marco Schmidt wrote:
>> Dear colleagues,
>> 
>> A new RIPE Policy proposal, 2019-07, "Default assignment size for IXPs"
>> is now available for discussion.
> 
> My suggestion :
> - if the default assignment size is to be lowered, that should be a /25 or a /26, not smaller.
> - The "target use" (currently "50% within 2 years"), should be a little more relaxed (either 3 years, or something like 35%-40% use within 2 years). 
> 
> I wouldn't mind reserving space for future enlargement (with reservations being re-allocated or reduced when space is needed by other members), but I think wording for that would render the policy way too complex.

Isn’t that as simple as “use sparse allocation”? As long as less than half of the remaining IXP pool has been used up, everyone can be given an allocation within a larger block with the ability to grow at least 2x.

-Scott

Radu-Adrian FEURDEAN

2019-11-13 20:52:37 CET


On Wed, Nov 13, 2019, at 15:04, Scott Leibrand wrote:
> Isn’t that as simple as “use sparse allocation”? As long as less than 
> half of the remaining IXP pool has been used up, everyone can be given 
> an allocation within a larger block with the ability to grow at least 
> 2x.

If "sparse allocation" is the magic word, it's OK for me. 

-- 
Radu-Adrian FEURDEAN

Scott Leibrand

2019-11-13 21:58:57 CET

On Wed, Nov 13, 2019 at 11:54 AM Radu-Adrian FEURDEAN <
ripe-wgs _at_ radu-adrian.feurdean _dot_ net> wrote:

>
>
> On Wed, Nov 13, 2019, at 15:04, Scott Leibrand wrote:
> > Isn’t that as simple as “use sparse allocation”? As long as less than
> > half of the remaining IXP pool has been used up, everyone can be given
> > an allocation within a larger block with the ability to grow at least
> > 2x.
>
> If "sparse allocation" is the magic word, it's OK for me.
>

I don't know, does that do what you want?  :-)

Sparse allocation would mean that each IXP assignment would be out of the
block containing the greatest number of adjacent bits of unused space.
That could be implemented either on an absolute basis (all allocations go
into the biggest unused CIDR block available), or on a bit-shift basis. For
a bit-shift sparse allocation strategy, if you have a free pool large
enough to shift 4 bits, you'd assign /24s out of empty /20s, /27s out of
empty /23s, etc. Then once you run out of blocks to accomplish that at
4-bit shift, you'd switch to 3 bits, and eventually down to 2 and then 1
bit before you have to give up on sparse allocation entirely.

The disadvantage of sparse allocation is that it purposefully breaks up
larger blocks, which may result in a lack of contiguous space for the
largest IXPs sooner than would otherwise occur, in order to allow earlier
IXPs to more easily grow their assignments. This is particularly acute with
an absolutely sparse strategy, where the biggest blocks get broken up
immediately, regardless of how tiny their allocations are. A bit-shift
sparse allocation policy, or similarly a "reserved space" strategy, avoids
that issue by limiting how much space is reserved for each IXP to grow into.

-Scott

Nick Hilliard

2019-11-14 14:56:14 CET

Radu-Adrian FEURDEAN wrote on 13/11/2019 13:41:
> A little late, but here's my point of view:
> - /27 is borderline for a default. Hopefully the 50% use within 2
> years should alleviate this (even if I find it not enough).
> - Anything smaller than a /27 is close to useless. - Renumbering is
> painful and should be avoided as much as possible.
> - IXP growth may be very variable in time. You may struggle for1-2
> years, then add several dozens members the next year. You may easy
> get in a situation when renumbering falls in a period of rapid
> growth, which only makes things worse.
The purpose of a policy should be to fix a specific problem.

As you're speaking in favour of the proposal, can you describe what 
problem you want to see fixed here?

Nick

Radu-Adrian FEURDEAN

2019-11-14 18:46:20 CET

On Thu, Nov 14, 2019, at 14:56, Nick Hilliard wrote:
> As you're speaking in favour of the proposal, can you describe what 
> problem you want to see fixed here?

Problem : adapt the default assignment to the needs of most, in order to prolong pool's life, while allowing those that need to grow to do so while minimising re-numbering at maximum.

To put it other way, I'm in favour of the idea, but not in favour of the current wording.

-- 
Radu-Adrian FEURDEAN

Nick Hilliard

2019-11-15 13:22:08 CET

Radu-Adrian FEURDEAN wrote on 14/11/2019 17:46:
> On Thu, Nov 14, 2019, at 14:56, Nick Hilliard wrote:
>> As you're speaking in favour of the proposal, can you describe
>> what problem you want to see fixed here?
> 
> Problem : adapt the default assignment to the needs of most, in order
> to prolong pool's life, while allowing those that need to grow to do
> so while minimising re-numbering at maximum.

It looks like the pool is probably large enough to last indefinitely 
under the current assignment policy.  It's not clear what changing the 
assignment policy is going to fix.

Nick


User Image

Gert Doering

2019-11-15 13:26:31 CET

Hi,

On Fri, Nov 15, 2019 at 12:22:08PM +0000, Nick Hilliard wrote:
> Radu-Adrian FEURDEAN wrote on 14/11/2019 17:46:
> > On Thu, Nov 14, 2019, at 14:56, Nick Hilliard wrote:
> >> As you're speaking in favour of the proposal, can you describe
> >> what problem you want to see fixed here?
> > 
> > Problem : adapt the default assignment to the needs of most, in order
> > to prolong pool's life, while allowing those that need to grow to do
> > so while minimising re-numbering at maximum.
> 
> It looks like the pool is probably large enough to last indefinitely 
> under the current assignment policy.  It's not clear what changing the 
> assignment policy is going to fix.


Not wanting to stop a lively discussion, but technically we're behind
the end of the discussion period and Remco is supposed to decide on
"does the proposer want to proceed, rewrite, withdraw" now.

Do we need more time?  Or has any substantial argument been made, and
everything else is just repetition now?

Gert Doering
        -- APWG chair
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

Kai 'wusel' Siering

2019-11-15 14:28:25 CET

Moin,

am 15.11.19 um 13:22 schrieb Nick Hilliard:
> It's not clear what changing the assignment policy is going to fix.

As far as I can see, it would give a use case for the fragmented space RIPE NCC holds, while saving on the final IXP-v4 addresses at the same time?

Regards,
-kai