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) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong <o...@delong.com> wrote: > >> On Feb 24, 2015, at 12:38 , Dean Pemberton <d...@internetnz.net.nz> wrote: >> >> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong <o...@delong.com> 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 sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
