Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN
My opinion is, if you are buying a single homed transit + peering, you are
multihoming.
However, if you are sub-allocated addresses from your upstream (non
portable) + peering, you are doing something undesirable (in my personal
opinion. Yours personal opinion may vary)
I think if you have a portable address block, and have demonstrated need
for an ASN (hint: just say peering), then you should be able to get one or
more (hint: just say discontiguous network) - which is not very different
from the current policy.
On 25/2/15 5:02 am, "Dean Pemberton" <dean at internetnz dot net dot nz> wrote:
>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 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
>>
>* sig-policy: APNIC SIG on resource management policy
> *
>_______________________________________________
>sig-policy mailing list
>sig-policy at lists dot apnic dot net
>http://mailman.apnic.net/mailman/listinfo/sig-policy