Dear Community members, I strongly oppose this proposal as there is no need to reduce further from /23, If one IX operator is going to open multiple IX nodes which are not inter-connected,the company needs more than /24 for each. I agree with Kabir and further suggest proposer to amend for increasing the size from /23 to /24 per Independent IX node for promoting the IX community. Regards, Ajai Kumar
On Thu, 10 Aug 2023 at 07:45, Md Alamgir Kabir <[email protected]> wrote: > > Dear Concern; > > Greetings from NIX-BD !!! > Good luck with a new proposal "prop-154-v001. Resizing the IPv4 assignment > for IXPs should get input from those who have worked in the practical > field. IXP is a small field but its vision works on a much larger scale. In > terms of PoP-expansion of IXPs depends on market dynamics factors such as > availability of ISPs, CDNs and Telcos. such as in marginal areas where new > IXPs will be planned and set up. The proposal does not in any way promote > or assist in the expansion of IXP. The default size of IP assignments > cannot be /23 to /26 by any means. So this proposal is > irrelevant for IXP.Please feel free to contact us for any further > information in this regard. > > *With Kinds Regards* > *------------------------------* > *Md Alamgir Kabir* > *ISPAB-NIX* > *Mobile Number # +880-1711435267* > *Skype# kabirrana5* > > > > > > On Tue, Aug 8, 2023 at 10:12 AM Shaila Sharmin < > [email protected]> wrote: > >> Dear SIG members, >> >> A new proposal "prop-154-v001: Resizing of IPv4 assignment for the IXPs" has >> been sent to the Policy SIG for review. >> >> It will be presented at the Open Policy Meeting (OPM) at APNIC 56 on >> Thursday, >> 14 September 2023. >> >> https://conference.apnic.net/56/program/program/#/day/8/ >> >> We invite you to review and comment on the proposal on the mailing list >> before >> the OPM. >> >> The comment period on the mailing list before the OPM is an important part >> of the Policy Development Process (PDP). >> We encourage you to express your views on the proposal: >> >> - Do you support or oppose this proposal? >> - Does this proposal solve a problem you are experiencing? If so, >> tell the community about your situation. >> - Do you see any disadvantages in this proposal? >> - Is there anything in the proposal that is not clear? >> - What changes could be made to this proposal to make it more >> effective? >> >> Information about this proposal is appended below as well as available at: >> >> http://www.apnic.net/policy/proposals/prop-154 >> >> Regards, >> Bertrand, Shaila, and Anupam >> APNIC Policy SIG Chairs >> >> >> --------------------------------------------------------------- >> >> prop-154-v001: Resizing of IPv4 assignment for the IXPs >> >> ---------------------------------------------------------------- >> >> Proposer: Simon Sohel Baroi ([email protected]) >> 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 the places the resources have been under-utilised and >> new >> IXPs are wasting a large >> amount of valuable IPv4 spaces. 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 number >> 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 /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 /24 when they can justify having >> more than 100 peers on >> the IXP fabric (peering LAN) in the next 12 months. >> >> If it is a national IXP and the said economy doesn’t have more than 60 >> registered APNIC members >> or resource holders (from other RIRs or legacy space holders) then there >> is no justification to >> have more than /27 assignments. >> >> An IXP which received an assignment less than /24 can request upto /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 80% of existing >> assignments. The existing assignment must be returned by the IXP within 3 >> months of the new assignment. >> >> Any resources less than /24 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. >> >> >> 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. >> >> >> 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. >> >> >> 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/[email protected]/ >> To unsubscribe send an email to [email protected] > > _______________________________________________ > SIG-policy - https://mailman.apnic.net/[email protected]/ > To unsubscribe send an email to [email protected] -- (M) +91-9868477444 Skype ID:erajay P-mail: joinajay1 at gmail.com ................................. Please don't print this email unless you really need to. This will preserve trees on our planet.
_______________________________________________ SIG-policy - https://mailman.apnic.net/[email protected]/ To unsubscribe send an email to [email protected]
