Hi Skeeve,

I don't think we have a policy to reclaim those AS Numbers. 

Regards,
Guangliang 

On 25 Feb 2015, at 7:57 pm, "Skeeve Stevens" <skeeve@v4now.com> wrote:

Guangliang,

What are the rules about someone with a ASN, later de-multi-homing?


...Skeeve

Skeeve Stevens - Senior IP Broker
v4Now - an eintellego Networks service
IP Address Brokering - Introducing sellers and buyers

On Wed, Feb 25, 2015 at 6:53 PM, Guangliang Pan <gpan@apnic.net> wrote:
Hi Gaurab,

If they can provide 2 peer ASNs in their application, based on the policy they can receive an ASN assignment.

Regards,
Guangliang

> On 25 Feb 2015, at 6:10 pm, "Gaurab Raj Upadhaya" <gaurab@lahai.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Guangliang,
>
> can you clarify these questions for me.
>
> If a provider connects to a v4 only transit provider over a physical
> circuit, but does v6 transit from Hurricane Electric over a tunnel,
> would that be considered multihoming ?
>
>
> - -gaurab
>
>
>
>> On 2/25/15 4:05 AM, Guangliang Pan wrote:
>> Hi Dean and All,
>>
>> According to the current APNIC ASN policy document, the definition
>> of multihomed is as below.
>>
>> http://www.apnic.net/policy/asn-policy#3.4
>>
>> 3.4 Multihomed
>>
>> A multi-homed AS is one which is connected to more than one other
>> AS. An AS also qualifies as multihomed if it is connected to a
>> public Internet Exchange Point.
>>
>> In the ASN request form, you will be asked to provide the estimate
>> ASN implementation date, two peer AS numbers and their contact
>> details. It is also acceptable if your network only connect to an
>> IXP.
>>
>> Best regards,
>>
>> Guangliang =========
>>
>> -----Original Message----- From: sig-policy-bounces@lists.apnic.net
>> [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Dean
>> Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen
>> DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy]
>> [New Policy Proposal] prop-114: Modification in the ASN eligibility
>> criteria
>>
>> Looks like a clarification on the definition of multi-homing from
>> the secretariat is what we need before being able to proceed here.
>>
>>
>> -- Dean Pemberton
>>
>> Technical Policy Advisor InternetNZ +64 21 920 363 (mob)
>> dean@internetnz.net.nz
>>
>> To promote the Internet's benefits and uses, and protect its
>> potential.
>>
>>
>> On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong <owen@delong.com>
>> wrote:
>>>
>>>> On Feb 24, 2015, at 12:38 , Dean Pemberton
>>>> <dean@internetnz.net.nz> wrote:
>>>>
>>>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong <owen@delong.com>
>>>> wrote:
>>>>>> Firstly I agree with Randy here.  If you're not multi-homed
>>>>>> then your routing policy can not be 'unique' from your
>>>>>> single upstream.  You may wish it was, but you have no way
>>>>>> to enforce this.
>>>>>
>>>>> This is not true.
>>>>>
>>>>> You can be single homed to a single upstream, but, have other
>>>>> peering relationships with other non-upstream ASNs which are
>>>>> also not down-stream. These relationships may not be
>>>>> sufficiently visible to convince APNIC that one is
>>>>> multihomed, even though technically it is a multihomed
>>>>> situation.
>>>>
>>>> I don't agree (Damn and we were getting on so well this year
>>>> =) ).
>>>>
>>>> I would argue that the situation you describe above DOES
>>>> constitute multihoming.
>>>
>>> I agree, but it may not necessarily constitute “multihoming” in a
>>> manner that is recognized or accepted by the RIR.
>>>
>>> Clarification from APNIC staff on the exact behavior from APNIC
>>> could render this moot.
>>>
>>> However, I have past experience where RIRs have rejected peerings
>>> with related entities and/or private ASNs of third parties as not
>>> constituting valid “multihoming” whereupon I had to resort to “a
>>> unique routing policy”.
>>>
>>>
>>>> If an LIR were connected to an upstream ISP but also wanted to
>>>> participate at an IXP I would consider them to be multihomed
>>>> and covered under existing APNIC policy.
>>>
>>> What if they only connected to the IXP with a single connection?
>>> I’ve also encountered situations where this is considered “not
>>> multihomed” and to be a “unique routing policy”.
>>>
>>>>
>>>> I couldn't find the strict definition on the APNIC pages as to
>>>> what the hostmasters considered multihoming to be, but if one
>>>> of them can point us to it then it might help.
>>>
>>> Agreed.
>>>
>>>>
>>>>
>>>>> While I oppose that (and thus completely oppose the other
>>>>> proposal), as stated above, I think there are legitimate
>>>>> reasons to allow ASN issuance in some cases for organizations
>>>>> that may not meet the multi-homing requirement from an APNIC
>>>>> perspective.
>>>>
>>>> I really want to find out what those multi-homing requirements
>>>> are. I suspect that they amount to "BGP connections to two or
>>>> more other ASNs" In which case I think we can go back to
>>>> agreeing.
>>>
>>> As long as it’s not more specific than that (for example, two or
>>> more public ASNs or via distinct circuits, etc.).
>>>
>>>
>>>>
>>>>
>>>>> I think it is more a case that smaller and simpler policy
>>>>> proposals that seek to change a single aspect of policy are
>>>>> more likely to succeed or fail on their merits, where large
>>>>> complex omnibus proposals have a substantial history of
>>>>> failing on community misunderstanding or general avoidance of
>>>>> complexity.
>>>>
>>>> I can see your point, but taking a smaller simpler approach is
>>>> only valid once you have agreed on the larger more strategic
>>>> direction.  I don't believe that we have had those
>>>> conversations.
>>>
>>> I find that in general, the larger the group you are attempting
>>> to discuss strategy with, the smaller the chunks necessary for a
>>> useful outcome.
>>>
>>> YMMV.
>>>
>>>> We are seeing small proposals purporting to talk about
>>>> multihoming, but what they are in essence talking about is the
>>>> much larger topic of the removal of demonstrated need (as
>>>> Aftab's clarification in the other thread confirms beyond
>>>> doubt.)
>>>
>>> Upon which clarification, you will notice that I switched to
>>> outright opposition to that policy. Frankly, you caught a
>>> subtlety in the language that I missed where I interpreted the
>>> proposal to still require justified need rather than mere
>>> announcement, but a careful re-read and the subsequent
>>> clarification of intent made it clear that I had erred.
>>>
>>> Further, note that I have always opposed this proposal as
>>> written, but offered as an alternative a much smaller change
>>> which I felt met the intent stated by the proposer without the
>>> radical consequences you and I both seem to agree are
>>> undesirable.
>>>
>>>> There is danger in the death by a thousand cuts.  Many times
>>>> you can't see the unintended consequences until you are already
>>>> down the track of smaller simpler policy changes.
>>>
>>> I really don’t think that is a risk in this case.
>>>
>>>> As we are in Japan I offer a haiku:
>>>>
>>>> A frog in water doesn’t feel it boil in time. Do not be that
>>>> frog.
>>>>
>>>> (http://en.wikipedia.org/wiki/Boiling_frog)
>>>
>>> I wish I could be at the meeting, but, alas, I’m here in the US
>>> looking on from afar.
>>>
>>> Owen
>> *              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 *
>> 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
>
>
> - --
>
> http://www.gaurab.org.np/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>
> iEYEARECAAYFAlTtg1QACgkQSo7fU26F3X3nSACfZayuWmeykSI2WzjhOZ0AO9rY
> I+kAoM863V5skin8wC/7sYaFfmhpwiTu
> =YRGr
> -----END PGP SIGNATURE-----
*              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