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]
