Hi Satoru,
I hope you are fine. It's really great to hear from you that, you have already
arranged a local discussion on prop-127.
As mentioned in proposal, decreasing the maximum allocation size from /22 to
/23 can prolong the last 103/8 pool so more small startups can still be
connected with multi-homing.
>From my point of view, as IPv4 is not a durable solution for anyone right now,
>so "delegating less IPv4 addresses to more organizations" is better than
>"delegating much IPv4 addresses to less organizations"
If the maximum delegation size can be reduced to /23 than more organizations
can get IPv4 addresses in this crisis period of IPv4 exhaustion which can be
vital for their businesses to start and they have the rights to get that I
think.
So it seems a very timely proposal to prolong the final 103/8 pool and we
really need this.
My comments are below on some of your raised points.
* I am worried that the change a allocation size and this discussion will be
repeated each time the 103/8 address pool decreases.* It should be /24 in this
time if it will be changed it in the future.
* I'd like to know the reason why "/23", not "/24" or other prefix size.
----- I think, decreasing the allocation size to /23 is more suitable for
multi-homing along with traffic load sharing.If it is /24 then multi-homing is
possible but traffic load sharing will not work.And other options such as /25
or /26 etc are not possible as per current best practices you know.
* /23 seems too small for a newcomer.
---- Yep, /23 seems too small, but there is no better options available i think.
Let's have some more discussion from other community members on prop-127. And
lastly thanks again for your concern.
Thanks & Regards,
Md. Abdullah Al NaserDhaka, Bangladesh
On Friday, February 22, 2019, 9:30:15 AM GMT+6,
sig-policy-requ...@lists.apnic.net <sig-policy-requ...@lists.apnic.net> wrote:
Send sig-policy mailing list submissions to
sig-policy@lists.apnic.net
To subscribe or unsubscribe via the World Wide Web, visit
https://mailman.apnic.net/mailman/listinfo/sig-policy
or, via email, send a message with subject or body 'help' to
sig-policy-requ...@lists.apnic.net
You can reach the person managing the list at
sig-policy-ow...@lists.apnic.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of sig-policy digest..."
Today's Topics:
1. Re: Prop-127 announcement : Change maximum delegation size
of 103/8 IPv4 address, pool to a /23 (Satoru Tsurumaki)
2. Re: prop-128-v001: Multihoming not required for ASN
(Satoru Tsurumaki)
----------------------------------------------------------------------
Message: 1
Date: Fri, 22 Feb 2019 12:29:08 +0900
From: Satoru Tsurumaki <satoru.tsurum...@g.softbank.co.jp>
To: Policy SIG <sig-pol...@apnic.net>
Subject: Re: [sig-policy] Prop-127 announcement : Change maximum
delegation size of 103/8 IPv4 address, pool to a /23
Message-ID:
<CAHXx+kT8=c1bczocna-mmptrkst--pohlpv8lnpbq5abfgq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Colleagues,
I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
I would like to share a feedback in our community for prop-127,
based on a meeting we organized on 12th Feb to discuss these proposals.
Almost half of participants were oppose the proposal and almost other half
ware neutral.
Many opposing comments were expressed with the reasons below:
* I am worried that the change a allocation size and this discussion
will be repeated each time the 103/8 address pool decreases.
* It should be /24 in this time if it will be changed it in the future.
* I'd like to know the reason why "/23", not "/24" or other prefix size.
* /23 seems too small for a newcomer.
* A Newcomer can choose a transfer as a alternative if the proposal not
reach consensus.
Best Regards,
Satoru Tsurumaki
JPOPF-ST
2019?1?18?(?) 15:17 Bertrand Cherrier <b.cherr...@micrologic.nc>:
> Dear SIG members,
>
> The proposal "prop-127-v001: Change maximum delegation size of 103/8
> IPv4 address pool to a /23" has been sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 47 in
> Daejeon, South Korea on Wednesday, 27 February 2019.
>
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
>
> The comment period on the mailing list before an APNIC meeting is an
> important part of the policy development process. 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 available at:
>
> http://www.apnic.net/policy/proposals/prop-127
>
> Regards
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> ------------------------------
>
> prop-127-v001: Change maximum delegation size of 103/8 IPv4 address
> pool to a /23
> ------------------------------
>
> Proposers: Ching-Heng Ku, Aftab Siddiqui, Yen-Chieh Wang
> c...@twnic.tw
> 1. Problem Statement
>
> This is a proposal to change the maximum size of IPv4 address delegations
> from the APNIC 103/8 IPv4 address pool [1] to a /23.
> 2. Objective of policy change
>
> The current final /8 allocation policy[1] requires that the current minimum
> delegation size for IPv4 is a /24 and each APNIC account holder is only
> eligible
> to receive IPv4 address delegations totalling a maximum /22 from the
> APNIC 103/8
> IPv4 address pool.
>
> According to the APNIC IPv4 Address Report, https://ipv4.potaroo.net/,
> remaining
> addresses in the APNIC 103/8 pool are 42.8%, 33.3%, 23.4% of /8 in the
> end of
> 2016, 2017, and 2018, respectively. The remaining number of APNIC 103/8
> IPv4
> address pool for APNIC account holder is less and less. It is predicted
> that
> the 103/8 pool will be exhausted in 2020.
>
> Reducing the maximum IPv4 delegation size from APNIC 103/8 IPv4 address
> pool can
> prolong the exhaustion time of the 103/8. Newcomers of APNIC account
> holders will
> have the benefit in this period of time. New companies can obtain some
> IPv4 address
> space in the APNIC service region without the need to trade for address
> space and
> can make the preparation for the subsequent IPv6 migration.
>
> It is recommended that the number of assigned IPv4 addresses in Final /8
> be reduced
> from a maximum of /22 to /23. It will be estimated to extend the
> exhaustion time
> for at least three years or more.
> 3. Situation in other regions
>
> There is no similar policy in place in other RIR regions.
> 4. Proposed policy solution
>
> It is proposed to modify the 6.1 Minimum and maximum IPv4 delegations of
> the APNIC
> Internet Number Resource Policies[1].
>
> This proposal is to change the maximum size of IPv4 address delegations
> from the
> APNIC 103/8 IPv4 address pool[1] to a /23. /23 is important because new
> ISPs can
> use /24 for internal infrastructure and /24 customer assignments and NAT
> for IPv6
> transition.
>
> Current Policy text
>
> Each APNIC account holder is only eligible to receive IPv4 address
> delegations
> totalling a maximum /22 from the APNIC 103/8 IPv4 address pool.
>
> New Policy text
>
> Each APNIC account holder without APNIC 103/8 IPv4 address delegations
> from the
> APNIC 103/8 IPv4 address pool is only eligible to receive a maximum /23
> from the
> APNIC 103/8 IPv4 address pool.
> 5. Advantages / Disadvantages
>
> Advantages:
> - This proposal allows a greater range of networks to access the
> resources in
> the final /8.
>
> - This proposal extends the maximum possible total number of networks
> that can benefit from the final /8 pool from around 16,000 to around 18,000
> networks, providing small amounts of IPv4 to be available for networks,
> developing economy, etc., making the transition to IPv6 for many years to
> come.
>
> Disadvantages:
> - No disadvantages are foreseen.
> 6. Impact on resource holders
>
> It reduces the maximum size of the delegated address block available to
> APNIC
> members during the final /8 phase. This will affect NIR members in the
> same way
> as APNIC members.
> 7. References
>
> [1] Section 6.1. "Minimum and maximum IPv4 delegations" of "Policies for
> IPv4 address
> space management in the Asia Pacific region"
> https://www.apnic.net/community/policy/resources#Part-2-IPv4-Policy
> * sig-policy: APNIC SIG on resource management policy
> *
> _______________________________________________
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mailman.apnic.net/mailing-lists/sig-policy/attachments/20190222/86d41f19/attachment.html>
------------------------------
Message: 2
Date: Fri, 22 Feb 2019 12:29:20 +0900
From: Satoru Tsurumaki <satoru.tsurum...@g.softbank.co.jp>
To: Policy SIG <sig-pol...@apnic.net>
Subject: Re: [sig-policy] prop-128-v001: Multihoming not required for
ASN
Message-ID:
<CAHXx+kRLtrjD-5ow4TCR_=qFv2x9qnsjamp+UCX=cwtsbap...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Colleagues,
I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
I would like to share a feedback in our community for prop-128,
based on a meeting we organized on 12th Feb to discuss these proposals.
Substantial support expressed, subject to not deleting the
"it holds previously-allocated provider independent address space"
described in the current policy text.
* In this proposal, "it holds previously-allocated provider independent
address space" is erased. it should keep it in order to prevent unnecessary
application of AS number.
* In the case of IPv6, the NAT disappears and the global address is assigned
to all device in the organization. If each organization uses a PI address
that is not locked in to a upper provider, there is a great merit that
there is no need to procure the second transit.
*There are areas where have only one transit as pointed out by the proposer.
This proposal has the effect that policy conforms to the actual situation
as a result.
Best Regards,
Satoru Tsurumaki
JPOPF-ST
2019?1?22?(?) 9:14 Bertrand Cherrier <b.cherr...@micrologic.nc>:
> Dear SIG members,
>
> The proposal "prop-128-v001: Multihoming not required for ASN" has been
> sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 47 in
> Daejeon, South Korea on Wednesday, 27 February 2019.
>
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
>
> The comment period on the mailing list before an APNIC meeting is an
> important part of the policy development process. 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 available at:
>
> http://www.apnic.net/policy/proposals/prop-128
>
> Regards
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> ------------------------------
>
> prop-128-v001: Multihoming not required for ASN
> ------------------------------
>
> Proposers: Jordi Palet Mart?nez
> jordi.pa...@theipv6company.com
> 1. Problem Statement
>
> When the ASN assignment policy was originally designed, the reliability
> of networks was not so good as today. So, at that time, it was making
> sense to make sure that and ASN holder is multihomed.
>
> However, today this is not necessarily a reasonable requirement, and
> even in some cases, some networks may require an ASN and not willing
> to be multihomed (because the cost, or remote locations that have only
> a single upstream, etc.), and their SLA requirements don?t need that
> redundancy.
>
> The deployment of IPv6 also increase the need for organizations which
> are not ISPs, to obtain IPv6 PI in order to have stable addresses,
> and in that situation, ideally, they should announce their PI space
> with their own ASN. In most cases, they don?t have to be multihomed.
> 2. Objective of policy change
>
> To ensure that organizations which have their own routing policy and
> the need to interconnect with other organizations, can do it.
>
> Interconnect is used here with the commonly understood meaning of
> establishing a connection between two (administratively) separate
> networks.
> 3. Situation in other regions
>
> ARIN and LACNIC don?t require multihoming. RIPE requires it. AfriNIC has
> a policy equivalent to APNIC, but I?m submitting a proposal similar to
> this one to change it as well as in the case of RIPE.
> 4. Proposed policy solution
>
> Current Policy text
>
> 12.1. Evaluation of eligibility
>
> An organization is eligible for an ASN assignment if:
> - it is currently multihomed, or
> - it holds previously-allocated provider independent address space and
> intends to multihome in the future.
>
> An organization will also be eligible if it can demonstrate that it will
> meet the above criteria upon receiving an ASN (or within a reasonably
> short time thereafter).
>
> Requests for ASNs under these criteria will be evaluated using the
> guidelines described in RFC1930 'Guidelines for the creation, selection
> and registration of an Autonomous System' (AS).
>
> Proposed text
>
> 12.1. Evaluation of eligibility
>
> An organization is eligible for an ASN assignment if:
> - it is multihomed or
> - has the need to interconnect with other AS.
>
> An organization will also be eligible if it can demonstrate that it will
> meet any
> of the above criteria upon receiving an ASN (or within a reasonably
> short time thereafter).
>
> Requests for ASNs under these criteria will be evaluated using the
> guidelines described in RFC1930 'Guidelines for the creation, selection
> and registration of
> an Autonomous System' (AS).
> 5. Advantages / Disadvantages
>
> Advantages:
> Fulfilling the objectives above indicated.
>
> Disadvantages:
> None foreseen.
> 6. Impact on resource holders
>
> None.
> 7. References
>
> https://www.arin.net/policy/nrpm.html#five
> https://www.lacnic.net/683/2/lacnic/
> https://www.ripe.net/publications/docs/ripe-679
> * sig-policy: APNIC SIG on resource management policy
> *
> _______________________________________________
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mailman.apnic.net/mailing-lists/sig-policy/attachments/20190222/8d5d0945/attachment.html>
------------------------------
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy
End of sig-policy Digest, Vol 177, Issue 4
******************************************
* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy
