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/address-policy-wg@ripe.net/
[address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
- Previous message (by thread): [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
- Next message (by thread): [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore at fud.no
Fri May 31 09:08:30 CEST 2019
* Marco Schmidt > A new RIPE Policy proposal, 2019-05, "Revised IPv4 assignment policy for IXPs" is now available for discussion. I am positive to this policy proposal. A suggestion, though: use the /16 set aside in «5.2 Unforeseen circumstances» for expanding the IXP pool. The unforeseen circumstances reservation is 185.0.0.0/16 while the IXP pool is 185.1.0.0/16. They combine nicely into 185.0.0.0/15. This might be helpful for operators that might want to exempt known IXP ranges from uRPF filtering, for example. Also, I am wondering about the thinking behind giving out /24s by default when the minimum assignment size is reduced /27. Why not right-size the assignment all the way down to the minimum assignment size, thus maximising the amount of future entrants the pool can support? There's nothing special about the /24 boundary for the IXP use case, to the best of my knowledge. Tore
- Previous message (by thread): [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
- Next message (by thread): [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]