I would think it would... why does it matter how you get to another peer?


...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:09 PM, Gaurab Raj Upadhaya <gaurab@lahai.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guangliang,

can you clarify these questions for me.

If a provider connects to a v4 only transit provider over a physical
circuit, but does v6 transit from Hurricane Electric over a tunnel,
would that be considered multihoming ?


- -gaurab



On 2/25/15 4:05 AM, Guangliang Pan 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
>


- --

http://www.gaurab.org.np/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iEYEARECAAYFAlTtg1QACgkQSo7fU26F3X3nSACfZayuWmeykSI2WzjhOZ0AO9rY
I+kAoM863V5skin8wC/7sYaFfmhpwiTu
=YRGr
-----END PGP SIGNATURE-----
*              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