I don’t see any rational use case for a second or third ASN where it wouldn’t be peering with at least 2 ASNs.
If you can present one, then I could be convinced to reconsider. Owen > On Mar 4, 2015, at 16:46 , Skeeve Stevens <[email protected]> wrote: > > Owen, > > That is almost, but not quite ok. > > There may be cases where you have the same reason to do this for a second or > third ASN. > > Say I need one for an isolated network in HK, or NZ, or KH with a completely > separate routing policy? > > The same criteria should apply for the first and 10th? > > > ...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/> > > IP Address Brokering - Introducing sellers and buyers > > On Thu, Mar 5, 2015 at 9:30 AM, Owen DeLong <[email protected] > <mailto:[email protected]>> wrote: > I don’t feel the need for every use case to be set in stone, but I do think > that there are better ways to address this. > > Is there any reason that adding the following to the existing policy would be > unacceptable to you? > > … > or an organization which has received an assignment or allocation from APNIC > and has not previously obtained an ASN may obtain one ASN upon request for > purposes of setting up peering for their network with one or more other other > autonomous systems. > > > Why would that not suffice? > > Owen > >> On Mar 4, 2015, at 15:47 , Skeeve Stevens <[email protected] >> <mailto:[email protected]>> wrote: >> >> Owen, >> >> It just feels like nitpicking and moving chairs around. I actually trust >> the Secretariat to do the right thing when allocating resources. We're also >> talking about a resource where there are over 4.1 billion ASN's still >> available... not that it should be a justification to wastage, but it is >> useful for context. >> >> The APNIC stats are: >> >> How many ASN - % of Membership >> no ASN >> 34.06% >> 1 >> 56.59% >> 2 >> 5.55% >> 3 >> 1.78% >> 4 >> 0.77% >> 5 >> 0.35% >> 6 >> 0.28% >> 7 >> 0.15% >> 8 >> 0.04% >> 10 >> 0.13% >> more than 10 >> 0.31% >> >> I'm unsure why you guys want to see each and every use-case set in stone. I >> don't want to have to come back and do amendments picking on a word here or >> there because there has been an innovation in the way networks are operated. >> >> >> I fully support the idea that this isn't a free-for-all.. but we need some >> flexibility in the community. >> >> >> ...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/> >> >> IP Address Brokering - Introducing sellers and buyers >> >> On Thu, Mar 5, 2015 at 8:33 AM, Owen DeLong <[email protected] >> <mailto:[email protected]>> wrote: >> If said standard pre-existing procedure were subject to the PDP, I’d be fine >> with that. >> >> However, that’s not what the wording implies. In the case of the IPv6 >> policy, I think this is less than desirable, but it’s not on the table in >> this discussion. >> >> Certainly if someone proposed removing that wording from the IPv6 policy, I >> would support such a proposal. >> >> Owen >> >>> On Mar 4, 2015, at 14:58 , Skeeve Stevens <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Do we just move the 'proposed draft guidelines' to cases under 3.3? >>> >>> We were trying to be flexible for future use cases without going through >>> this painful process for every future valid use case that comes up in >>> future. >>> >>> This is an established process where for subsequent IPv6 allocations: >>> >>> === http://www.apnic.net/policy/ipv6-address-policy#5.3.2 >>> <http://www.apnic.net/policy/ipv6-address-policy#5.3.2> ==== >>> >>> 5.3.2 Alternative allocation criteria >>> >>> Alternatively, a subsequent allocation may be provided where an >>> organization (ISP/LIR) can demonstrate a valid reason for requiring the >>> subsequent allocation. For guidelines on what will be considered a valid >>> technical or other reason, see “APNIC guidelines for IPv6 allocation and >>> assignment requests”. >>> >>> http://www.apnic.net/ipv6-guidelines >>> <http://www.apnic.net/ipv6-guidelines> >>> === >>> >>> Why isn't a standard pre-existing procedure acceptable to you? >>> >>> >>> ...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/> >>> >>> IP Address Brokering - Introducing sellers and buyers >>> >>> On Thu, Mar 5, 2015 at 3:11 AM, Owen DeLong <[email protected] >>> <mailto:[email protected]>> wrote: >>> Opposed as written. >>> >>> Vague wording which basically says that the secretariat can decide policy >>> on a case-by-case >>> basis is antithetical to an informed multi-stakeholder community consensus >>> policy development >>> process. >>> >>> Owen >>> >>>> On Mar 4, 2015, at 00:02 , Masato Yamanishi <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Dear SIG members >>>> >>>> A new version of the proposal “prop-114: Modification in the ASN >>>> eligibility criteria" has been sent to the Policy SIG for review. >>>> >>>> Information about earlier versions is available from: >>>> >>>> http://www.apnic.net/policy/proposals/prop-114 >>>> <http://www.apnic.net/policy/proposals/prop-114> >>>> >>>> You are encouraged to express your views on the proposal: >>>> >>>> - Do you support or oppose the proposal? >>>> - Is there anything in the proposal that is not clear? >>>> - What changes could be made to this proposal to make it more effective? >>>> >>>> Please find the text of the proposal below. >>>> >>>> Kind Regards, >>>> >>>> Masato >>>> >>>> >>>> >>>> -------------------------------------------------------------------------- >>>> prop-114-v002: Modification in the ASN eligibility criteria >>>> -------------------------------------------------------------------------- >>>> >>>> Proposer: Aftab Siddiqui >>>> [email protected] >>>> <mailto:[email protected]> >>>> >>>> Skeeve Stevens >>>> [email protected] >>>> <mailto:[email protected]> >>>> >>>> >>>> 1. Problem statement >>>> ----------------------------- >>>> >>>> The current ASN assignment policy states two eligibility criteria >>>> and that both criteria should be fulfilled in order to obtain an >>>> ASN. The policy seems to imply that both requirements i.e. >>>> multi-homing and clearly defined single routing policy must be met >>>> simultaneously, this has created much confusion in interpreting the >>>> policy. >>>> >>>> As a result organizations have either provided incorrect information >>>> to get the ASN or barred themselves from applying where they still >>>> have a valid justification for obtaining an ASN. >>>> >>>> >>>> 2. Objective of policy change >>>> -------------------------------------- >>>> >>>> In order to make the policy guidelines simpler we are proposing to >>>> modify the text describing the eligibility criteria for ASN >>>> assignment by providing alternate criteria to obtaining an ASN. >>>> >>>> >>>> 3. Situation in other regions >>>> ------------------------------------ >>>> >>>> ARIN: >>>> It is not mandatory but optional to be multi-homed in order get ASN >>>> >>>> RIPE: >>>> Policy to remove multi-homing requirement is currently in discussion >>>> and the current phase ends 12 February 2015 (awaiting Chair >>>> decision) >>>> >>>> Policy - https://www.ripe.net/ripe/policies/proposals/2014-03 >>>> <https://www.ripe.net/ripe/policies/proposals/2014-03> >>>> >>>> LACNIC: >>>> Only inter-connect is mandatory not multi-homing >>>> >>>> AFRINIC: >>>> It is mandatory to be multi-homed in order to get ASN. >>>> >>>> >>>> 4. Proposed policy solution >>>> ----------------------------------- >>>> >>>> An organization is eligible for an ASN assignment if: >>>> >>>> - they are currently multi-homed OR >>>> >>>> - meet one of the other criteria in the guidelines managed by the >>>> APNIC Secretariat >>>> >>>> >>>> 5. Advantages / Disadvantages >>>> ----------------------------------------- >>>> >>>> Advantages: >>>> >>>> By adding the additional criteria of Guidelines managed by APNIC >>>> Secretariat, this would enable the Secretariat to make decisions >>>> based on common or rare use cases, but that may still be a valid >>>> request. >>>> >>>> Disadvantages: >>>> >>>> It may be perceived that this policy would enable members to obtain >>>> ASN’s more easily, and in return cause faster consumption of ASN’s >>>> in the region. Given the relative ease of obtaining an ASN with >>>> ‘work around’ methods, we do not perceive this will actually have >>>> any effect. >>>> >>>> >>>> >>>> 6. Impact on resource holders >>>> --------------------------------------- >>>> >>>> No impact on existing resource holders. >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> Proposed Draft Guidelines >>>> (to be created as a numbered document by APNIC) >>>> ------------------------------------------------------------------------ >>>> >>>> The below are example of guidelines that could be considered for >>>> alternate needs justification. >>>> >>>> The intention to multi-home in the future >>>> >>>> The applicant is participating in elastic fabrics where the >>>> requirements to connect to ‘on demand’ service providers may require >>>> ASN/BGP connectivity >>>> >>>> Regional limitation of obtaining multi-homing connectivity in the >>>> ‘immediate’ term, but want to design their networks for this capability >>>> >>>> Have a single unique routing policy different to their upstream, but >>>> yet >>>> are single-homed >>>> >>>> * 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://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://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
