I remain opposed to this proposal. It is an unnecessary and pointless rearranging of deck chairs with zero benefit to the community.
When we run out of /24s to give to new IXs, It is utterly harmless for IXs to become IPv6 only fabrics. IPv4 NRLI can be exchanged over IPv6 peering sessions with zero issues. Owen > On Sep 8, 2023, at 16:06, Shaila Sharmin <shaila.sharmin....@gmail.com> wrote: > > Dear SIG members, > > A new version of the proposal "prop-154: Resizing of IPv4 assignment for > the IXPs" > has been sent to the Policy SIG for review. > > Information about earlier versions is available from: > > http://www.apnic.net/policy/proposals/prop-154 > > You are encouraged to express your views on the proposal: > > - Do you support or oppose the proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more effective? > > Please find the text of the proposal below. > > Regards, > Bertrand, Shaila, and Anupam > APNIC Policy SIG Chairs > > > > --------------------------------------------------------------- > > prop-154-v002: Resizing of IPv4 assignment for the IXPs > > ---------------------------------------------------------------- > > Proposer: Simon Sohel Baroi (sba...@gmail.com <mailto:sba...@gmail.com>) > Aftab Siddiqui > > > 1. Problem statement > -------------------- > According to APNIC Internet Number Resource Policies ( Ref – APNIC-127, > Dated: 22 DEC, 2022 ), an Internet Exchange Point ( IXP ) is eligible to > receive a maximum /23 of IPv4 and /48 of IPv6 resources. Usually APNIC > assign one /24 to start a new IXP. But from analysis through PeeringDB, > we found most of places the resources have been underutilized and new > IXPs are wasting a large amount of valuable IPv4 space. On the other > side there are large IXP, who can’t grow due to lack of IP resources, > where /23 is not enough as the membership size is big. The size of the > minimum and maximum range of IP delegation to new or existing IXPs is > the main problem in the current policy. > > Present IXP Status in APAC region from PeeringDB [5] : > +-------------------+-------+------------+-------+---------------------------+ > | IX Names | Peers | ....Vs.... | Peers | IX > Names | > +-------------------+-------+ +-------+---------------------------+ > | BBIX Tokyo | 299 | | 17 | > BBIX-Thailand | > +-------------------+-------+ +-------+---------------------------+ > | JPIX TOKYO | 257 | | 3 | > MekongIX | > +-------------------+-------+ +-------+---------------------------+ > | Equinix Tokyo | 131 | | 2 | Equinix > Mumbai | > +-------------------+-------+ +-------+---------------------------+ > | JPNAP Tokyo | 211 | | 13 | npIX > JWL | > +-------------------+-------+ +-------+---------------------------+ > | HKIX | 296 | | 3 | Vanuatu Internet > Exchange | > +-------------------+-------+ +-------+---------------------------+ > | Equinix Hong Kong | 216 | | 4 | > MyNAP | > +-------------------+-------+ +-------+---------------------------+ > | Equinix Singapore | 422 | | 25 | DE-CIX Kuala > Lumpur | > +-------------------+-------+ +-------+---------------------------+ > | IIX-Jakarta | 449 | | 13 | > IIX-Lampung | > +-------------------+-------+ +-------+---------------------------+ > | DECIX-Mumbai | 446 | | 14 | Decix > Kolkata | > +-------------------+-------+ +-------+---------------------------+ > | MegaIX Sydney | 232 | | 46 | EdgeIX - > Melbourne | > +-------------------+-------+------------+-------+---------------------------+ > > > 2. Objective of policy change > ----------------------------- > The objective of this proposal is to modify the default size of IPv4 > assignments for IXPs from up to /23 to /26, which can receive a > replacement up to a maximum of a /22, provided the IXP returns the IPv4 > address space previously assigned to them. > > 3. Situation in other regions > ----------------------------- > Similar policy has been adopted by RIPE NCC ( ripe-733 : IPv4 Address > Allocation and Assignment Policies for the RIPE NCC Service Region ) [4] > > > 4. Proposed policy solution > --------------------------- > > Current Policy text : > > 6.2.4. IPv4 for Internet Exchange Points > > Internet Exchange Points (IXP) are eligible to receive a delegation from > APNIC to be used exclusively to connect the IXP participant devices to > the Exchange Point. > > Global routability of the delegation is left to the discretion of the > IXP and its participants. > > New Policy text : > > 6.2.4. IPv4 for Internet Exchange Points > > By default, a /26 of IPv4 address block will be assigned to the new IXPs. > > IXPs can seek an assignment of up to a /25 when they can justify having > more than 60 peers on the IXP fabric (peering LAN) in the next 12 months. > > IXPs can seek an assignment of up to a /23 or current highest assignment > size when they can justify having more than 100 peers on the IXP fabric > (peering LAN) in the next 12 months. > > An IXP which received an assignment less than /24 can request up to /23 > IPv4, only if 60% of the original assignment has been used. The existing > assignment must be returned by the IXP within 3 months of the new > assignment. > > Existing Large IXPs that already have used their maximum assignment of > /23 from current policy can request a contiguous block (if available) of > /22, only if they have already used 60% of existing assignment. The > existing assignment must be returned by the IXP within 3 months of the > new assignment. > > Any existing IXP that wants to open new POPs can request for more IPv4 > addresses (which will be allocated using the same principle as defined > above /26 and /25) as long as the total allocation doesn’t exceed /22. > > Any resources assigned under this policy will not be announced in the > global routing table (mistakes are exempted) and must be used for IXP > peering only, in case otherwise the resources will be revoked by APNIC. > > Global routability of the delegation outside this policy is left to the > discretion of the IXP and its participants. > > Any resources assigned under this policy will be non-transferable. > > Recommendation - APNIC should reserve up to /20 for IXPs under this policy > > > 5. Advantages / Disadvantages > ----------------------------- > Advantages: > This proposal will ensure rapid expansion of IXPs in terms of membership > and POP numbers for this region and smoothen allocation of IPv4. > Reducing the default assignment size to /26 would stop wasting a large > amount of valuable IPv4 space. Increasing the allocation size will help > the IXPs add more members in fabric very easily. > > Disadvantages: > When the IXP operator jumps into a bigger block of IPv4 and returns the > existing one, then they might be required to renumber all routers > connected to that IXP fabric (peering LAN). > > 6. Impact on APNIC > ------------------ > The IXP who already became an APNIC member and has less IPv4 Resources > can also apply for maximum delegation for their expansion. > > > 7. References > ------------- > [1] Section 6.2.4. IPv4 for Internet Exchange Points. > https://www.apnic.net/community/policy/resources#a_h_6_2_4 > > [2] Section 9.1.3. IPv6 for Internet Exchange Points. > https://www.apnic.net/community/policy/resources#a_h_9_1_3 > > [3] Section 11.1.2. Conditions on source of the transfer > https://www.apnic.net/community/policy/resources#a_h_11_1 > > [4] IPv4 Address Allocation and Assignment Policies for the RIPE NCC > Service Region https://www.ripe.net/publications/docs/ripe-733 > > [5] PeeringDB : https://www.peeringdb.com/ > _______________________________________________ > SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/ > To unsubscribe send an email to sig-policy-le...@lists.apnic.net
_______________________________________________ SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/ To unsubscribe send an email to sig-policy-le...@lists.apnic.net
