Thank you, Vivek. Aftab, so what I understand is, new IXPs will be at a disadvantage compared to other new applicants. Others can get a /23 initial, IXPs get a /26.
You had mentioned that this proposal would encourage IXs. On Tue, 12 Sep 2023, 13:29 Vivek Nigam, <vi...@apnic.net> wrote: > Hi Sanjeev, > > > > 1. We don't have a separate pool for IXP delegations. > > > > 2. Based on recent delegation trends, APNIC and NIRs combined delegate > about 280 /24's each month. > > > > Thanks > > Vivek > > > > *From: *Sanjeev Gupta <sanj...@dcs1.biz> > *Date: *Monday, 11 September 2023 at 2:35 pm > *To: *sig-policy <sig-policy@lists.apnic.net> > *Cc: *Aftab Siddiqui <siddi...@isoc.org> > *Subject: *[sig-policy] Re: New version: prop-154: Resizing of IPv4 > assignment for the IXPs > > Would the APNIC Secetariat please clarify (for IPv4): > > > > 1. Are IXP allocations made from a separate pool? If so, > > > 1. What is the free size of the pool > 2. What is the rate of depletion > > > 1. What is the rate of depletion of the general (final /8) pool? > > I am trying to understand what we will achieve by holding IXP allocations > to a tighter standard (/26) than general new signups, which get a /23 > anyway. > > > > > > > > > > -- > Sanjeev Gupta > +65 98551208 http://sg.linkedin.com/in/ghane > <https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsg.linkedin.com%2Fin%2Fghane&data=05%7C01%7C%7C38ed677cc90a46c7215108dbb288e14b%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C638300073195866861%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WikbihZjC%2Bg0E%2BnQN51Nx2%2FscbLFAhC84yzBCZPLzf8%3D&reserved=0> > > > > > > On Sat, Sep 9, 2023 at 7:07 AM 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) > 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 > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.net%2Fpublications%2Fdocs%2Fripe-733&data=05%7C01%7C%7C38ed677cc90a46c7215108dbb288e14b%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C638300073195866861%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LIcPQ0IsSWUFwB1FrnEFOe%2BfcPjfnLHmFg4ICN5LU6c%3D&reserved=0> > > [5] PeeringDB : https://www.peeringdb.com/ > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.peeringdb.com%2F&data=05%7C01%7C%7C38ed677cc90a46c7215108dbb288e14b%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C638300073195866861%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=We1AwM%2FYWurO3%2B3zv%2BOyuiCrqspn5t8xyu873NCOPdw%3D&reserved=0> > > _______________________________________________ > 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
