According to the current APNIC ASN policy document, the definition
of multihomed is as below.
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.
-----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.
To promote the Internet's benefits and uses, and protect its
potential.
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