Re: [sig-policy] prop-128-v001: Multihoming not required for ASN

  • To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
  • Subject: Re: [sig-policy] prop-128-v001: Multihoming not required for ASN
  • From: Owen DeLong <owen@delong.com>
  • Date: Wed, 27 Feb 2019 09:28:13 -0800
  • Cc: Policy SIG <sig-policy@apnic.net>
  • Delivered-to: sig-policy@clove.apnic.net
  • Dkim-filter: OpenDKIM Filter v2.11.0 owen.delong.com x1RHSEkB012767
  • Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1551288494; bh=M/Vn2pXNH4b3Vf95EZcmxttMpgYtRf6GA/johcFb7R8=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=1qXDGJGYRJSFeOxZf2VsITXybSDJSO/G6fkxFxaCWgJ+t6Ks5sK3iqDo4I3JvfWmu Yn3SGcSwOgXu6WdFneUOARbHqVleWjB0cd9CS6Gy2jbnFgbrMuYrkfhyvv3wm/clh3 /weTf+VGSe+uUMbJU89FbVugdsRTR+RdUUAhX7Ek=
  • In-reply-to: <7EFD6670-6EA6-43DC-9D86-C2AF88BA8381@consulintel.es>
  • List-archive: <http://mailman.apnic.net/mailing-lists/sig-policy/>
  • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
  • List-post: <mailto:sig-policy@lists.apnic.net>
  • List-subscribe: <https://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <https://mailman.apnic.net/mailman/options/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
  • References: <01A7318F-77D9-4E71-A451-CE573E1657A6@micrologic.nc> <CAHXx+kRLtrjD-5ow4TCR_=qFv2x9qnsjamp+UCX=cWtSbapT-A@mail.gmail.com> <F2B2ADB5-B9CA-42E6-8D7C-1B63AD5A704C@consulintel.es> <64818F1F-4A7F-4621-9552-DC80349BF2BA@delong.com> <7EFD6670-6EA6-43DC-9D86-C2AF88BA8381@consulintel.es>

    • The point is, I’ve no doubt that the staff is smart to allow two consecutive requests for addresses first and one instant after the ASN. However, this is totally artificial in my opinion. No need for that.

      It’s not artificial…

      If you don’t have IP addresses, then you don’t have a routing policy and you don’t need an ASN.

      If you are applying simultaneously for both, that’s all well and good and I’m sure that APNIC staff will serialize the requests for you to cope with the policy requirements.
       
      Second main issue. Yes, people can commit fraud, but policies should not “facilitate that” if we can avoid it. Asking people to say “I will multihome”, is not coherent if not verified, so let’s try to avoid “promises”.

      I agree, but I don’t think asking people to provide some bare minimum assurance that they need a resource before we give it to them is “facilitating fraud”. I think it’s “responsible number resource policy”.

      I think that the idea of giving out resources without first making some rudimentary verification of legitimate need is not “preventing fraud”, it’s actually "facilitating irresponsible resource usage" (which I don’t think we should do either).

      Owen


      Regards,

      Jordi

       

       
       
      De: Owen DeLong <owen@delong.com>
      Fecha: viernes, 22 de febrero de 2019, 19:00
      Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
      CC: Satoru Tsurumaki <satoru.tsurumaki@g.softbank.co.jp>, Policy SIG <sig-policy@apnic.net>
      Asunto: Re: [sig-policy] prop-128-v001: Multihoming not required for ASN
       
       


      On Feb 21, 2019, at 22:20 , JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
       
      Hi again Satoru, and once more many thanks for the inputs,
       
      If we keep “it holds previously-allocated provider independent address space”, then it means an organization, for example, deploying only IPv6, will not be able to get an ASN.
       
      Why can’t they get previously-allocated IPv6 Provider Independent space?
       

      Or even an organization willing to get IPv4, can’t get it from APNIC. Should them then wait for available IPv4 space and not have their own ASN meanwhile?
       
      If they don’t have address space to advertise, what, exactly, are they going to use the AS Number for in the mean time?
       
      I’m not opposed to deleting the phrase, but I am truly curious if you have an actual use case where removing it is harmful.
       

      Or should they “promise” “I will multihome” and actually never do it? (there is no a concrete time term defined in the policy).
       
      Ideally, no.
       

      Or going to the extreme. Should the organization get IPv4 PI, but actually not use it?
       
      This part still doesn’t make sense to me. The phrase mentioned does not specify IPv4, yet you seem to be assuming that is a requirement. Am I missing something?
       

      Or should the organization request IPv6 PI today and tomorrow an ASN ? It is artificial!
       
      Previously doesn’t necessarily mean separation by days. I think that the RIR staff can be trusted to accept applications contemporaneously and issue the addresses first, followed by he ASN, thus meeting the requirement in the policy.
       
      If you have a better way to address the issue they are bringing up, then propose that and let’s discuss it as a community.
       
      As I understand their message, the concern is issuing ASNs that have no actual use/need. I don’t think anyone is trying to put up artificial barriers to entry, but there is a desire to ensure that ASN acquisition doesn’t become some form of network fashion statement.
       

      If we really want to ensure that those organizations multihome, we really need to fix in how much time, and that was already changed in proposal 114. I think this proposal improves that, going to the point where probably prop-114 wanted to be (but sometimes you need to go step by step …).
       
      I seem to recall Skeeve put forth a proposal to eliminate the multihoming requirement some years back because it was becoming problematic in a number of situations where peering was desirable, but multihoming couldn’t necessarily be achieved (or at least had a longer than permitted time frame).
       
      At the time, I had suggested the use of “Multihomed or otherwise demonstrate a unique routing policy.” which actually pretty well covers any situation in which you would need an ASN.
       

      In general, I don’t think restricting non-scarce resources as ASN is a good thing, and if that happens APNIC should report it back to the community and then we may consider it back.
       
      Having trouble parsing this sentence. If restriction of the resources occurs, it will be through policy, so I’m not sure what APNIC would need to report back to the community.
       

      Current text is artificial in the sense that already prop-114 expressed. People can just lie “I will …”.
       
      People can commit fraud in a number of ways in a variety of circumstances. I don’t think that the answer in most situations is to permit all the benefits by removing the rules to make it impossible to commit fraud (or at least pointless). It’s sort of like saying “Everyone on this freeway is always doing 200Kph, therefore we should raise the speed limit to 200Kph.” If someone obtains resources from a falsified application, then they are committing fraud and I’m sure the APNIC legal team is quite capable of addressing that situation should sufficient evidence come to light.
       
      Owen



      Regards,

      Jordi

       

       
       
      De: <sig-policy-bounces@lists.apnic.net> en nombre de Satoru Tsurumaki <satoru.tsurumaki@g.softbank.co.jp>
      Fecha: viernes, 22 de febrero de 2019, 12:30
      Para: Policy SIG <sig-policy@apnic.net>
      Asunto: Re: [sig-policy] prop-128-v001: Multihoming not required for ASN
       
      Dear Colleagues,
       
      I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
       
      I would like to share a feedback in our community for prop-128,
      based on a meeting we organized on 12th Feb to discuss these proposals.
       
      Substantial support expressed, subject to not deleting the 
      "it holds previously-allocated provider independent address space" 
      described in the current policy text.
       
      * In this proposal, "it holds previously-allocated provider independent 
      address space" is erased. it should keep it in order to prevent unnecessary
      application of AS number.
       
      * In the case of IPv6, the NAT disappears and the global address is assigned
      to all device in the organization. If each organization uses a PI address
      that is not locked in to a upper provider, there is a great merit that
      there is no need to procure the second transit.
       
      *There are areas where have only one transit as pointed out by the proposer.
      This proposal has the effect that policy conforms to the actual situation
      as a result.
       
       
      Best Regards,
       
      Satoru Tsurumaki
      JPOPF-ST
       
      2019122() 9:14 Bertrand Cherrier <b.cherrier@micrologic.nc>:
      Dear SIG members,
      The proposal "prop-128-v001: Multihoming not required for ASN" has been
      sent to the Policy SIG for review.
      It will be presented at the Open Policy Meeting at APNIC 47 in
      Daejeon, South Korea on Wednesday, 27 February 2019.
      We invite you to review and comment on the proposal on the mailing list
      before the meeting.
      The comment period on the mailing list before an APNIC meeting is an
      important part of the policy development process. We encourage you to
      express your views on the proposal:
      · Do you support or oppose this proposal?
      · Does this proposal solve a problem you are experiencing? If so, tell the community about your situation.
      · Do you see any disadvantages in this proposal?
      · Is there anything in the proposal that is not clear?
      · What changes could be made to this proposal to make it more effective?
      Information about this proposal is available at:
      Regards
      Sumon, Bertrand, Ching-Heng
      APNIC Policy SIG Chairs

      prop-128-v001: Multihoming not required for ASN

      Proposers: Jordi Palet Martínez
      jordi.palet@theipv6company.com

      1. Problem Statement

      When the ASN assignment policy was originally designed, the reliability
      of networks was not so good as today. So, at that time, it was making
      sense to make sure that and ASN holder is multihomed.
      However, today this is not necessarily a reasonable requirement, and
      even in some cases, some networks may require an ASN and not willing
      to be multihomed (because the cost, or remote locations that have only
      a single upstream, etc.), and their SLA requirements don’t need that
      redundancy.
      The deployment of IPv6 also increase the need for organizations which
      are not ISPs, to obtain IPv6 PI in order to have stable addresses,
      and in that situation, ideally, they should announce their PI space
      with their own ASN. In most cases, they don’t have to be multihomed.

      2. Objective of policy change

      To ensure that organizations which have their own routing policy and
      the need to interconnect with other organizations, can do it.
      Interconnect is used here with the commonly understood meaning of
      establishing a connection between two (administratively) separate
      networks.

      3. Situation in other regions

      ARIN and LACNIC don’t require multihoming. RIPE requires it. AfriNIC has
      a policy equivalent to APNIC, but I’m submitting a proposal similar to
      this one to change it as well as in the case of RIPE.

      4. Proposed policy solution

      Current Policy text
      12.1. Evaluation of eligibility
      An organization is eligible for an ASN assignment if:
      - it is currently multihomed, or
      - it holds previously-allocated provider independent address space and
      intends to multihome in the future.
      An organization will also be eligible if it can demonstrate that it will
      meet the above criteria upon receiving an ASN (or within a reasonably
      short time thereafter).
      Requests for ASNs under these criteria will be evaluated using the
      guidelines described in RFC1930 'Guidelines for the creation, selection
      and registration of an Autonomous System' (AS).
      Proposed text
      12.1. Evaluation of eligibility
      An organization is eligible for an ASN assignment if:
      - it is multihomed or
      - has the need to interconnect with other AS.
      An organization will also be eligible if it can demonstrate that it will
      meet any
      of the above criteria upon receiving an ASN (or within a reasonably
      short time thereafter).
      Requests for ASNs under these criteria will be evaluated using the
      guidelines described in RFC1930 'Guidelines for the creation, selection
      and registration of
      an Autonomous System' (AS).

      5. Advantages / Disadvantages

      Advantages:
      Fulfilling the objectives above indicated.
      Disadvantages:
      None foreseen.

      6. Impact on resource holders

      None.

      7. References

      *              sig-policy:  APNIC SIG on resource management policy           *
      _______________________________________________
      sig-policy mailing list
      sig-policy@lists.apnic.net
      https://mailman.apnic.net/mailman/listinfo/sig-policy
      * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.nethttps://mailman.apnic.net/mailman/listinfo/sig-policy

      **********************************************
      IPv4 is over
      Are you ready for the new Internet ?
      http://www.theipv6company.com
      The IPv6 Company

      This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

      *              sig-policy:  APNIC SIG on resource management policy           *
      _______________________________________________
      sig-policy mailing list
      sig-policy@lists.apnic.net
      https://mailman.apnic.net/mailman/listinfo/sig-policy



      **********************************************
      IPv4 is over
      Are you ready for the new Internet ?
      http://www.theipv6company.com
      The IPv6 Company

      This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.