Please see my other email Phil.. there is very valid reasons for this policy change.
...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 4:25 PM, Philip Smith <[email protected]> wrote: > Dean Pemberton wrote on 25/02/2015 15:06 : > > 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. > > Same, I simply don't understand what problem is trying to be solved here. > > If an organisation is connected to only one other organisation, there is > no need for an ASN. If these two orgs want to use BGP, that's a private > matter, and is what private ASNs are for - and there are now around 1 > billion of those. > > If an organisation needs to connect to at least two other ASNs, then > they qualify under the APNIC definition which Guanliang shared. > > philip > -- > > > > > I do not support the proposal > > > > > > -- > > 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 5:05 PM, Guangliang Pan <[email protected]> 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 > > > * 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
