Hi Aftab, I understand your point. My concern is, how do these new/small IXPs announce their hosted content (LAN) to global routing as they are receiving /26 at the first stage? We should consider this situation.
Regards / Jahangir Hossain On Wed, Sep 13, 2023 at 3:42 PM Aftab Siddiqui <[email protected]> wrote: > Hi Jahangir, > Peering lan should never be on the global routing table whether you > support this policy or not. Even the peering lan of existing IXP are not > advertised to global routing table. > > On Wed, 13 Sep 2023 at 6:14 pm, Jahangir Hossain <[email protected]> > wrote: > >> I also remain opposed to this proposal and inessential. >> >> if a new IXP is required to announce some content to global routing then >> how does this new IXP announce this block /26? >> >> Regards / >> Jahangir Hossain >> >> >> >> >> >> >> On Sat, Sep 9, 2023 at 5:06 AM Shaila Sharmin < >> [email protected]> 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 ([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 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 >>> >>
_______________________________________________ SIG-policy - https://mailman.apnic.net/[email protected]/ To unsubscribe send an email to [email protected]
