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

Reply via email to