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 [email protected] ; www.v4now.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4now ; <http://twitter.com/networkceoau> linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com IP Address Brokering - Introducing sellers and buyers On Wed, Feb 25, 2015 at 5:09 PM, Gaurab Raj Upadhaya <[email protected]> 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: [email protected] > > [mailto:[email protected]] On Behalf Of Dean > > Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen > > DeLong Cc: [email protected] 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) > > [email protected] > > > > To promote the Internet's benefits and uses, and protect its > > potential. > > > > > > On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong <[email protected]> > > wrote: > >> > >>> On Feb 24, 2015, at 12:38 , Dean Pemberton > >>> <[email protected]> wrote: > >>> > >>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong <[email protected]> > >>> 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 [email protected] > > http://mailman.apnic.net/mailman/listinfo/sig-policy * > > sig-policy: APNIC SIG on resource management policy * > > _______________________________________________ sig-policy mailing > > list [email protected] > > 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 > [email protected] > http://mailman.apnic.net/mailman/listinfo/sig-policy >
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
