What he said...

Mark.

On 28/Feb/15 05:25, David Huberman wrote:
> Hello,
>
> [Please pardon the top posting. I am on a mobile device.]
>
> Regarding your sentence:
>
> "Any subsequent allocations [of an AS number] would fall under the
> same criteria, plus the extra burden of justification by the
> secretariat to justify additional ASNs."
>
> I humbly request the draft policy authors, the working group
> community, and the APNIC staff to think carefully about how such
> policy language will be written, and how such a policy would be
> implemented.
>
> My experiences have taught me that the answer to the question, "why do
> you need an additional AS number?" is not easily captured in either
> policy language or RIR procedures. Why? Because networks are not all
> built the same.
>
> In well-known situations, there are both regulatory and market-based
> forces which sometimes back network operators into engineering designs
> which lack polish. Secondly, network architects like to apply creative
> solutions to complex situations. What this means in the real world of
> network operations is that just because you would design Network X to
> use one AS number doesn't mean I designed it that way; my solution
> calls for two or three AS numbers.  And this is important because the
> RIR (in both its AS number policies and its internal procedures for
> reviewing requests) needs to recognize that when a network operator
> states he needs an additional AS number, he probably does.
>
> Most importantly, the RIR staff should not be put in a position to
> have to fully understand a network architecture and
> be required to adjudicate its worthiness for an additional AS number.
>
> Thank you for any consideration you can give to this matter, and I
> look forward to our discussions this week in Fukuoka.
>
> David R Huberman
> Microsoft Corporation
> Principal, Global IP Addressing
> ------------------------------------------------------------------------
> *From:* sig-policy-boun...@lists.apnic.net
> <sig-policy-boun...@lists.apnic.net> on behalf of Skeeve Stevens
> <ske...@v4now.com>
> *Sent:* Friday, February 27, 2015 5:45:12 PM
> *Cc:* sig-policy@lists.apnic.net
> *Subject:* [sig-policy] Prop-114: Modification in the ASN eligibility
> criteria - explanation.
>  
> Hi all,
>
> Having read (most of) the feedback, Aftab and I will be putting a new
> version out probably either late Sunday or Early Monday.  I am at
> Haneda Airport flying to Fukuoka now and Aftab arrives in Tokyo and I
> believe will be arriving tomorrow morning. Once we've had time to
> confer, we will issue new wording.
>
> The object of this policy is to remove the need to be multi-homed to
> get your */initial/* ASN.  It is not designed to hand out ASN's like
> candy, not provide them to people who have no intention of multi-homing.
>
> It is designed for those who wish to announce their portable ranges
> via their own ASN using whatever routing policy they determine to be
> appropriate for the operation of their network, but removing the
> requirement to be immediately multi-homed, but having the intention to
> multi-home at some point (the timeframe should not be mandated) -
> whether that be permanently or not is not relevant.
>
> Any subsequent allocations would fall under the same criteria, plus
> the extra burden of justification by the secretariat to justify
> additional ASN's.
>
> The wording will be based around the above.
>
> The cases for this policy are numerous and the reasons Aftab and I are
> doing this together is to address several of them.
>
> - Entities not meeting the multi-homing criteria due to economic
> circumstances, regional access, etc.
>
> - Smaller entities, such as businesses with portable address space
> that would like more control and flexibility over how they announce
> their networks, and plan for multi-homing either as a future facility
> or for cloud/elastic on demand purposes.
>
> The major use case from my perspective is:
>
> - Due to IP runout (ISPs having less and charging more), and some
> requirements for being portable, I am assisting *many* businesses
> become APNIC members and their own address space.  Many of these
> initially are not multi-homed, but are planning to in the short period
> as they consider the elastic infrastructure available to them over new
> initiatives like Megaport and others - where layer 2, BGP to many
> 'service' providers is the new way of doing business.  I did a
> presentation on Megaport and Elastic X-Connect Fabrics at the last
> APNIC in Brisbane for those who saw it.
>
> In Australia (and I am sure other places too), there is the new
> concept of opportunistic capacity - being able to buy transit on an
> as-needs basis for any determined time period... 1 week, 1 day, even
> hourly.  An operator might be single homed, but may wish to bring on
> elastic/On Demand transit capacity for short periods of time - at
> which point the would be multi-homed, but then disconnect and then be
> single-homed again.
>
> Here is a news article about this
> offering: 
> http://www.itwire.com/business-it-news/networking/65730-intabank-partners-with-megaport
>
> Megaport is across Australia ,Singapore, Hong Kong, New Zealand and
> heading for the US and Europe - as well as other elastic fabrics such
> as Pacnet's PEN, Equinix Cloud Exchange, IX Australia and others
> coming.  This way of doing business will be commonplace for businesses
> in certain regions rapidly over 2015 - especially as 
>
> To cater for this explosion in elastic fabrics and marketplaces that
> serve them, the policy framework has to facilitate a smooth way of
> doing this new 'cloud' kind of business - without businesses having to
> 'fudge the truth' to get thr required resources.
>
> APNIC has ability to do rapid memberships within a very short period
> (1 day) with address space and ASN's up and running very quickly.
>
> This is the key reason for my proposed change to policies 113 and 114,
> as well as supporting Aftabs motivations on assisting smaller
> providers in regional areas, or economically challenged locations
> where multi-homing is not as easy as it might be elsewhere, prepare
> their networks to participate in being multi-homed for the standard
> reasons.
>
> If you have any comments about this, or have any advice on wording,
> restrictions, we would love to hear from you by tomorrow PM so we can
> consider your thoughts and also any perceived problems with the policy
> and (preferably) with ways to meet the need, but deal with any
> potential abuse.
>
> Thanks.
>
>
>
> ...Skeeve
>
> *Skeeve Stevens - Senior IP Broker*
> *v4Now - *an eintellego Networks service
> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com
> <http://www.v4now.com/>
>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>
> facebook.com/v4now
> <http://facebook.com/v4now> ; linkedin.com/in/skeeve
> <http://linkedin.com/in/skeeve>
>
> twitter.com/theispguy <http://twitter.com/theispguy> ;
> blog: www.theispguy.com <http://www.theispguy.com/>
>
>
> IP Address Brokering - Introducing sellers and buyers
>
>
>     -----------------------------------------------------------
>     prop-114-v001: Modification in the ASN eligibility criteria
>     -----------------------------------------------------------
>
>     Proposer:     Aftab Siddiqui
>                   aftab.siddi...@gmail.com
>     <mailto:aftab.siddi...@gmail.com>
>
>                   Skeeve Stevens
>                   ske...@eintellegonetworks.com
>     <mailto:ske...@eintellegonetworks.com>
>
>
>     1. Problem statement
>     --------------------
>
>         The current ASN assignment policy dictates two eligibility
>     criteria
>         and both should be fulfilled in order to get an ASN. The policy
>         seems to imply that both requirements i.e. multi-homing and
>     clearly
>         defined single routing policy must be met simultaneously, this has
>         created much confusion in interpreting the policy.
>
>         As a result organizations have either provided incorrect
>     information
>         to get the ASN or barred themselves from applying.
>
>
>     2. Objective of policy change
>     -----------------------------
>
>         In order to make the policy guidelines simpler we are proposing to
>         modify the text describing the eligibility criteria for ASN
>         assignment by removing multi-homing requirement for the
>     organization.
>
>
>     3. Situation in other regions
>     -----------------------------
>
>     ARIN:
>         It is not mandatory but optional to be multi-homed in order
>     get ASN
>
>     RIPE:
>         Policy to remove multi-homing requirement is currently in
>     discussion
>         and the current phase ends 12 February 2015
>             Policy - https://www.ripe.net/ripe/policies/proposals/2014-03
>
>     LACNIC:
>         only inter-connect is mandatory not multi-homing
>
>     AFRINIC:
>          It is mandatory to be multi-homed in order to get ASN.
>
>
>     4. Proposed policy solution
>     ---------------------------
>
>         An organization is eligible for an ASN assignment if it:
>          - Is planning to use it within next 6 months
>
>
>     5. Advantages / Disadvantages
>     -----------------------------
>
>     Advantages:
>
>         Removing the mandatory multi-homing requirement from the
>     policy will
>         make sure that organizations are not tempted to provide wrong
>         information in order to fulfil the criteria of eligibility.
>
>     Disadvantages:
>
>         No disadvantage.
>
>
>     6. Impact on resource holders
>     -----------------------------
>
>         No impact on existing resource holders.
>
>
>     7. References
>     -------------
>
>
>     *              sig-policy:  APNIC SIG on resource management
>     policy           *
>     _______________________________________________
>     sig-policy mailing list
>     sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net>
>     http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>

*              sig-policy:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Reply via email to