-----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
