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