Sorry, to clarify.

There is already an existing process for subsequent ASN process which the
secretariat follows (I think?).  I am not intending on changing anything to
do with that... just the initial ASN allocation.


...Skeeve

*Skeeve Stevens - Senior IP Broker*
*v4Now - *an eintellego Networks service
[email protected] ; www.v4now.com

Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve

facebook.com/v4now ;  <http://twitter.com/networkceoau>
linkedin.com/in/skeeve

twitter.com/theispguy ; blog: www.theispguy.com


IP Address Brokering - Introducing sellers and buyers

On Sat, Feb 28, 2015 at 12:25 PM, David Huberman <
[email protected]> 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:* [email protected] <
> [email protected]> on behalf of Skeeve Stevens <
> [email protected]>
> *Sent:* Friday, February 27, 2015 5:45:12 PM
> *Cc:* [email protected]
> *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
>  [email protected] ; www.v4now.com
>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>
> facebook.com/v4now ;  <http://twitter.com/networkceoau>
> linkedin.com/in/skeeve
>
> twitter.com/theispguy ; blog: www.theispguy.com
>
>
>  IP Address Brokering - Introducing sellers and buyers
>
>
>> -----------------------------------------------------------
>> prop-114-v001: Modification in the ASN eligibility criteria
>> -----------------------------------------------------------
>>
>> Proposer:     Aftab Siddiqui
>>               [email protected]
>>
>>               Skeeve Stevens
>>               [email protected]
>>
>>
>> 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
>> [email protected]
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>>
>
*              sig-policy:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
[email protected]
http://mailman.apnic.net/mailman/listinfo/sig-policy

Reply via email to