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

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