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] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)
- Previous message (by thread): [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)
- Next message (by thread): [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore at fud.no
Mon Jan 16 11:09:58 CET 2023
Forgot to mention one thing, see below. (I am quoting my entire previous message so both can be replied to in-line at once.) * Tore Anderson > * Angela Dall'Ara > > > A new RIPE Policy Proposal, 2023-01, "Reducing IXP IPv4 assignment > > default size to a /26" > > is now available for discussion. > > > > The goal of this proposal is to extend the lifetime of the IXP IPv4 > > address pool and to motivate IXPs to implement the exchange of IPv4 > > routing information over IPv6. > > Hi, > > This proposal is a step in the right direction, although I feel it > should have gone further. I've already elaborated on why in the «IXP > pool lower boundary of assignments» thread, so I don't seek to re-hash > that whole thread, but for the record I'll repeat the gist of it in the > formal proposal thread: > > Since IPv4 is a finite resource that needs to last "forever", it seems > wasteful to willfully assign too large prefixes to IXPs that do not > need them. According to https://github.com/mwichtlh/address-policy-wg, > a /26 would be excessively large for a majority of IXPs. > > I would rather see a policy that did not specify a default size at all, > but rather instructed the NCC to right-size each assignment according > to the "at least 50% utilisation after a year" rule. > > Note that this should not be considered an objection to this proposal, > as I mentioned before it is a step in the right direction, after all. > > With that out of the way, I have a few questions/comments: > > 1) Regarding «New IXPs will be initially assigned a /26 by default. > Upon request, a /25 can be assigned initially. If the initial > assignment has been utilised by at least 50%, IXPs can request the > assignment of a /24»: > > This is somewhat difficult to decipher. Does it mean that: > > a) a new IXP can simply ask for an initial /25 and receive it, no > questions asked? > b) an existing IXP that has used 50% of an initial /26 will be able to > upgrade straight to a /24, i.e., bypassing a /25? (Or even %50-of- > /27→/24, in an unlikely but not impossible corner case.) > > To improve clarity, I would suggest not to mix the conditions for new > IXPs / initial assignments with the conditions for already existing > IXPs that seek to upgrade a previous assignment. > > > 2) Regarding «Assignments strictly larger than a /24 will only be made > to IXPs that offer the exchange of IPv4 routing information over IPv6 > at their route servers»: > > a) What is the purpose / meaning of the word «strictly» here? I assume > it is there for a reason, but removing it does not seem to me to change > the meaning of the sentence in any way (but then again, I am not a > native English speaker). > > b) Depending on whether one considers an assignment from the NCC to the > IXPs as to be a continuous state or as a one-time event, this may cause > an instant obligation on current holders of larger-than-/24 IXP > prefixes to implement IPv4-over-IPv6 routing in their route servers. Is > that the intention? 3) Regarding «On request or once there are no more available assignments of /26 (or larger), assignments can be made down to /27.»: I suggest this proposal adds the current (and future) non-assignable «space dust» (prefixes smaller than /24) in the NCC's inventory to the IXP pool. Considering that IXPs is one of the few use cases where this «space dust» is useful, and that this proposal opens up for assignments of such small prefixes from the IXP pool, it seems logical to open up for the similar use of the small prefixes currently not part of the IXP pool as well. However, when we are at at a point in time where the IXP pool is completely empty except for such «space dust», why restrict the assignment size to /27? It seems to me that if we have reached a point in time where the only thing remaining in the IXP pool is «space dust» smaller than /27, and there is a small new IXP that could make use of, say, a /28, I see no reason to deny the IXP receiving that assignment. Therefore I suggest replacing «assignments can be made down to /27» with «smaller assignments can be made» or something along those lines. Tore
- Previous message (by thread): [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)
- Next message (by thread): [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]