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/[email protected]/
[address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
- Previous message (by thread): [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
- Next message (by thread): [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Andy Davidson
andy at nosignal.org
Wed Oct 26 10:18:58 CEST 2011
On 25 Oct 2011, at 19:06, Remco Van Mook wrote: > 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. Agreed. Andy
- Previous message (by thread): [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
- Next message (by thread): [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]