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] ; 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 6:53 PM, Guangliang Pan <[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]> > 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]] 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 > > > > > > - -- > > > > 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] > 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
