Hi Skeeve, I don't think we have a policy to reclaim those AS Numbers.
Regards, Guangliang On 25 Feb 2015, at 7:57 pm, "Skeeve Stevens" <[email protected]<mailto:[email protected]>> wrote: Guangliang, What are the rules about someone with a ASN, later de-multi-homing? ...Skeeve Skeeve Stevens - Senior IP Broker v4Now - an eintellego Networks service [email protected]<mailto:[email protected]> ; www.v4now.com<http://www.v4now.com/> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4now<http://facebook.com/v4now> ; <http://twitter.com/networkceoau> linkedin.com/in/skeeve<http://linkedin.com/in/skeeve> twitter.com/theispguy<http://twitter.com/theispguy> ; blog: www.theispguy.com<http://www.theispguy.com/> [http://eintellegonetworks.com/logos/v4now-web05.png] IP Address Brokering - Introducing sellers and buyers On Wed, Feb 25, 2015 at 6:53 PM, Guangliang Pan <[email protected]<mailto:[email protected]>> wrote: Hi Gaurab, If they can provide 2 peer ASNs in their application, based on the policy they can receive an ASN assignment. Regards, Guangliang > On 25 Feb 2015, at 6:10 pm, "Gaurab Raj Upadhaya" > <[email protected]<mailto:[email protected]>> wrote: > > -----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]> >> [mailto:[email protected]<mailto:[email protected]>] >> On Behalf Of Dean >> Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen >> DeLong Cc: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>> >> wrote: >>> >>>> On Feb 24, 2015, at 12:38 , Dean Pemberton >>>> <[email protected]<mailto:[email protected]>> wrote: >>>> >>>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong >>>> <[email protected]<mailto:[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]<mailto:[email protected]> >> http://mailman.apnic.net/mailman/listinfo/sig-policy * >> sig-policy: APNIC SIG on resource management policy * >> _______________________________________________ sig-policy mailing >> list [email protected]<mailto:[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]<mailto:[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
