> On Feb 24, 2015, at 22:06 , Dean Pemberton <d...@internetnz.net.nz> wrote: > > 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. >
Agreed… However, it does allow one to basically get ASNs no matter what, since all one needs to do is cobble up 3 distinct sites and ask for an ASN for each site and then peer the sites with each other. Owen > 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
