I agree that being this specific in policy might be overdoing it a bit, but at this point in time I don't want any ambiguity in ipv4 allocation policy and I'm not aware of any other kind of document where the community can put guidance on implementation.
> With some first hand experience in setting up Exchanges, I would suggest
> the following:
> - a new IXP gets a /24
> - an existing IXP that runs out of its /24 (whether from this /16 or
> another range) gets a /23 and has to return the old /24
> - an existing IXP that runs out of its /23 (whether from this /16 or
> another range) gets a /22 and has to return the old /23
> (Yes, this means renumbering every single time. Yes, it's a pain. Yes, if
> you run out of a /22 for your peering LAN you're fresh out of luck.)
This is sane logic, but it feels very much like userland^Wimplementation documentation rathe than policy to me. Agree ? I don't mind it being in the policy though as it sounds very sane.
> And while we're at it, I would suggest to add to 5.6.4:
> c. Any address space that is returned by an IXP will be added to the
> reserve as outlined in 5.6.2.
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.