Sorry Dean, I don't agree with you. You guys are trying to tell people how to run their networks, and that they aren't allowed to pre-emptively design their connectivity to allow for changing to multi-homing, or away from it, without going through a change in network configuration.
That might be easy for you, but that is simply your opinion on how things should be done... not a reason why others shouldn't be allowed to do it the way they want to. If a member has a portable range, they should be entitled to - with no restrictions - a ASN number to be able to BE as portable as they want to. ...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:20 PM, Dean Pemberton <[email protected]> wrote: > Nope - Your other email didn't provide any reasons which weren't covered > by Philips answer. > > If you have a peering session to two or more ASNs you are multihomed and > you qualify. > If you only peer with one ASN then you can do this with a private ASN. > If you want to make a change and move from a single peer to more than one > then you get quickly get an ASN. > You can even get them in advance of a planned network change as seen in > the current policy snippet below > > "An organization will also be eligible if it can demonstrate that it will > meet the above criteria upon receiving an ASN (or within a reasonably short > time thereafter)." > > No need to change policy. > > > > -- > 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:09 PM, Skeeve Stevens <[email protected]> wrote: > >> 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 >> >> >
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
