Dean,

I'm not debating the time it takes to get an ASN allocated... I'm talking about everything else around it... and changing your setup when you shouldn't even have to... again, you're telling people how to run their networks.

I'm simply saying that leave the running of the networks to them... let them decide when, if they multi-home, if they choose to de-multi-home, etc.

We all know we can lie our way around this... but people shouldn't have to... and if that is the only reason, then it is still a valid one.

A rule that isn't enforced, or has any repercussions for going around, shouldn't even be there in the first place.  If the only reason it remains is to annoy some small number of ethical people, it should be remediated.



...Skeeve

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

On Wed, Feb 25, 2015 at 5:35 PM, Dean Pemberton <dean@internetnz.net.nz> wrote:
Thanks for that Guangliang.  Thats really helped to clarify the position here.

Another question.
Whats the normal time lag between a member applying for an ASN
(assuming that all the information is present and correct) and it
being allocated?

1 day?
1 week?
1 month?

I'm trying to gauge if it really takes longer to apply for an ASN than
it does to arrange and configure a BGP peering session.

Thanks
Dean
--
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 5:05 PM, Guangliang Pan <gpan@apnic.net> 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