Hi Alamgir, Just for the sake of clarity, ISPAB-NIX already has a /23 IPv4 address block and if this IX wants to expand then prop-154 is actually providing a way to receive up to /22 i.e. 1024 IP addresses. Secondly, BD has 1811 ASN Delegations to-date so I'm not sure from where you got the 2500 plus number. Anyways, I still would like to hear your reasoning for opposing this policy
Regards, Aftab A. Siddiqui On Mon, 14 Aug 2023 at 15:01, Md Alamgir Kabir <[email protected]> wrote: > > Dear Concern ; > > Assalamu Alaikum > Greetings from NIX-BD !!! > I'm not really suggesting it. PeeringDB had a nice talk about the stats, > showing 51 peers not all logged into peering db. Hope everyone will enter > the peering DB. Bangladesh internet service provider internet company 2500 > plus and more ASN in Bangladesh.I hope you understand. Please feel free > to contact us for any further information in this regard. > > *With Kinds Regards* > *------------------------------* > *NIX KABIR* > > *Mobile Number # +880-1711435267* > *Skype# kabirrana5* > > > > > > On Mon, Aug 14, 2023 at 5:59 AM Aftab Siddiqui <[email protected]> > wrote: > >> Hi Alamgir, >> >> I'm not sure what you are suggesting here, firstly we are not discussing >> the IXP sustainability though it's a nice topic but of course out of the >> scope of policy discussion and certainly the proposed policy. The policy >> does actually provide provision to have up to /22 allocation if an IXP >> reaches 80% utilization which lets say is 400 Peers. Right now ISPAB-NIX >> (Bangladesh Internet Service Provider Internet Exchange Trust) has a /23 ( >> 103.161.216./23) IPv4 and /32 (2407:840::/32) IPv6 allocation, from the >> peeringdb stats it shows there are only 51 peers even the record is not up >> to date and giving benefit of doubt lets say there are 100 peers, but still >> there is no way to have more than 400 peers in the near future and even if >> that happens then you can still get /22 with the new policy. >> >> Would you like to elaborate further the reservations you have? >> >> Regards, >> >> Aftab A. Siddiqui >> >> >> On Fri, 11 Aug 2023 at 16:34, Md Alamgir Kabir <[email protected]> >> wrote: >> >>> >>> Dear concern; >>> >>> Assalamu Alaikum >>> Greetings from ISPAB-NIX !!! >>> All IXPs in the world need an experienced representation of how they >>> operate. >>> Then the idea of IPv4 can be found in IXP. IXP started in Bangladesh in >>> 2004. In terms of development, we need to have a plan on what kind of IXP >>> sustainability should be in our country. Along with that, we should think >>> about expanding content delivery network (CDN) to IXPs in our country. >>> Expanding thinking /23, /22 is not enough. IXPAB-NIX is planning on >>> that. IPV4 growth needs to be corrected.Please feel free to contact us for >>> any further information in this regard. >>> >>> *With Kinds Regards* >>> *------------------------------* >>> *NIX-KABIR* >>> *Mobile Number # +880-1711435267* >>> *Skype# kabirrana5* >>> >>> >>> >>> >>> >>> On Thu, Aug 10, 2023 at 9:51 PM Simon Sohel Baroi <[email protected]> >>> wrote: >>> >>>> Alamgir Vai, >>>> >>>> Thanks for your valuable inputs and comments. >>>> >>>> >>>> >>>> *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.-> *IXP plays a crucial role in >>>> Internet architecture.But among the 56 economies, not all markets are the >>>> same. Some small and some are big. A new IX has the potential to grow >>>> quickly and handle heavy traffic. IXPAB-NIX (NIX-BD) is an excellent >>>> instance. We made an effort to provide a step-up approach so that IXPs may >>>> expand quickly. Additionally, new IXPs should not waste unused IPv4 >>>> Resources. >>>> Today, obtaining IPV4 resources is fairly simple;however, tomorrow may >>>> be different. >>>> >>>> *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. >>>> * >>>> >>>> >>>> *-> *The proposal allows the IXPs to grow bigger and get upto /22, >>>> where the present policy is limited to /23. According to the expansion of >>>> IXPs in the area, all national level IXPs will soon need those kinds of >>>> resources. >>>> >>>> >>>> On Thu, Aug 10, 2023 at 8:15 AM 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] >>>> >>>> >>>> >>>> -- >>>> *Simon Sohel Baroi *| 45/c Senpara Parbata, Mirpur-10, Dhaka-1216 | >>>> Cell : +880-184-7102243 | Viber / Cell : +880-181-7022207 | >>>> Mail : [email protected] | Skype : tx.fttx | >>>> >>>> *Reduce. Reuse. Recycle. Respect. It's the little things that really >>>> can make a difference.* >>>> >>> _______________________________________________ >>> 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]
