Owen, See my case of the elastic network.
Using Megaport as an example, they are now online in Australia, Auckland, Singapore and Hong Kong and are going to many US cities next year. Each country (at the moment) fabric is an isolated infrastructure. So, if I wanted to put a connection online in Singapore, and only connected to one upstream, but also connect to Megaport, or Pacnets PEN - or to Megaports MLPA IX - which is state based - or other fabric, then I could need an ASN, and the routing policy would be unique to that location. Rinse and repeat for other locations. ...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 Thu, Mar 5, 2015 at 10:32 AM, Owen DeLong <[email protected]> wrote: > 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] ; 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 Thu, Mar 5, 2015 at 9:30 AM, Owen DeLong <[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]> 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] ; 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 Thu, Mar 5, 2015 at 8:33 AM, Owen DeLong <[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]> 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 ==== >>> >>> 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 >>> === >>> >>> Why isn't a standard pre-existing procedure acceptable to you? >>> >>> >>> ...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 Thu, Mar 5, 2015 at 3:11 AM, Owen DeLong <[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]> 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 >>>> >>>> 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] >>>> >>>> Skeeve Stevens >>>> [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 >>>> >>>> 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] >>>> 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 >>>> >>>> >>> >>> >> >> > >
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
