Great - Thanks for that. As far as I can tell this covers all possible use cases I can see. I do not believe that there is a need for prop-114.
I do not support the proposal -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan <g...@apnic.net> 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-boun...@lists.apnic.net > [mailto:sig-policy-boun...@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) > d...@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 <o...@delong.com> wrote: >> >>> On Feb 24, 2015, at 12:38 , Dean Pemberton <d...@internetnz.net.nz> wrote: >>> >>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong <o...@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
