I¹m with Dean on both counts. My opinion is, if you are buying a single homed transit + peering, you are multihoming.
However, if you are sub-allocated addresses from your upstream (non portable) + peering, you are doing something undesirable (in my personal opinion. Yours personal opinion may vary) I think if you have a portable address block, and have demonstrated need for an ASN (hint: just say peering), then you should be able to get one or more (hint: just say discontiguous network) - which is not very different from the current policy. On 25/2/15 5:02 am, "Dean Pemberton" <[email protected]> wrote: >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
