Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN
secretariat is what we need before being able to proceed here.
--
Dean Pemberton
Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
dean at internetnz dot net dot 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 at delong dot com> wrote:
>
>> On Feb 24, 2015, at 12:38 , Dean Pemberton <dean at internetnz dot net dot nz> wrote:
>>
>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong <owen at delong dot 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
>