[arin-ppml] ARIN-2018-1: Allow Inter-regional ASN Transfers

Tue Aug 14 09:48:15 EDT 2018

I stand corrected, but you must acknowledge the nearly 200  successful ASN transfers intra-regionally in APNIC as evidence that the need to transfer ASNs exists. We don’t need to posit hypotheticals for that, just look at the log of ASN transfers. Now we are just considering the source, and short ASNs are more prevalent in ARIN and RIPE than in APNIC.

APNIC and RIPE did the heavy lifting of establishing the processes at the RIRs to move ASNs as they now move IPv4 blocks. Clearly those communities also recognized some need for this policy.

I believe we have established that the need for ASN transfers exists, can somebody give us the downside of enacting this policy? Are we afraid that the short ASNs, which we say nobody really needs, will escape North America? Are we afraid to add a few short words to the NRPM?  Are we afraid that ARIN’s crackerjack staff won’t survive the onslaught?

As a reminder, stewards should govern with the lightest touch, responding to the needs of the community. The community is asking for this, has been for years, why not do it? 

Regards,

Mike

From: Owen DeLong <owen at delong.com> 
Sent: Monday, August 13, 2018 7:05 PM
To: Mike Burns <mike at iptrading.com>
Cc: Steven Ryerse <SRyerse at eclipse-networks.com>; ARIN-PPML List <arin-ppml at arin.net>
Subject: Re: [arin-ppml] ARIN-2018-1: Allow Inter-regional ASN Transfers

Correction…

APNIC and RIPE already have policy to support this process with no utilization.

Owen

On Aug 13, 2018, at 16:03 , Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:

I support the policy and note that:

The costs to implement are practically zero.

Some community members have requested this ability, who are we to gainsay their reasons?

The changes to the NRPM are tiny and discrete.

No downsides to the implementation this policy have been offered in any comments, if the need is tiny, so is ARIN staff time expended.

APNIC and RIPE are already engaged in this process with no ill effects.

Regards,

Mike

---- On Mon, 13 Aug 2018 19:00:28 -0400 Steven Ryerse < <mailto:SRyerse at eclipse-networks.com> SRyerse at eclipse-networks.com> wrote ----

+1

Steven Ryerse

President

100 Ashford Center North, Suite 110, Atlanta, GA  30338

770.656.1460 - Cell

770.399.9099 - Office

770.392.0076 - Fax

<1.jpg>℠ Eclipse Networks, Inc.

        Conquering Complex Networks℠

From: ARIN-PPML < <mailto:arin-ppml-bounces at arin.net> arin-ppml-bounces at arin.net> On Behalf Of Scott Leibrand

Sent: Monday, August 13, 2018 6:52 PM

To: Job Snijders < <mailto:job at ntt.net> job at ntt.net>

Cc: ARIN-PPML List < <mailto:arin-ppml at arin.net> arin-ppml at arin.net>

Subject: Re: [arin-ppml] ARIN-2018-1: Allow Inter-regional ASN Transfers

If you operate a network with peering sessions, and you are forced to renumber your ASN, you either need to convince all of your peers to set up new sessions (which can be a lot of work, and usually means at least some of them will refuse/fail to do so), or you need to local-as prepend the old ASN onto your new one, resulting in a longer AS path over that session.  Both outcomes are disruptive to a network's ability to maintain peering.

Given that there are valid technical and business justifications for needing to keep the same ASN on a network whose locus of control switches continents, I believe it is appropriate to allow organizations who need to do so to transfer administrative control of their ASN between RIRs, and therefore support this draft policy.

While it is certainly possible for some networks to easily renumber their ASN, that is not true of all networks, for valid technical reasons.  I therefore do not find arguments of the "I've never needed to do that" or "I can't imagine why someone would need to do that" informative or convincing.  To my mind, the only argument that would justify opposing ASN transfers would be one that details how such transfers would be burdensome to the RIRs or to the Internet community more generally, and would further show that such burden is greater than the benefit to those organizations it would help.  As I, Job, and others have detailed the kind of organization that would be benefited by this proposal, it's not sufficient to assert that such organization do not (or should not) exist.

-Scott

On Mon, Aug 13, 2018 at 3:36 PM Job Snijders < <mailto:job at ntt.net> job at ntt.net> wrote:

On Tue, 14 Aug 2018 at 01:23, Larry Ash < <mailto:lar at mwtcorp.net> lar at mwtcorp.net> wrote:

On Mon, 13 Aug 2018 14:47:09 -0700

  Owen DeLong < <mailto:owen at delong.com> owen at delong.com> wrote:

>> On Aug 13, 2018, at 14:42 , Job Snijders < <mailto:job at ntt.net> job at ntt.net> wrote:

>> 

>> I agree with the proposal.

>> 

>> I think this proposal is needed and addresses practical concerns: the alternative to transfers is “renumbering”, and renumbering 

>>ASNs is a very costly and operationally risky proposition. There is no upside to restricting or forbidding this type of resource 

>>transfer.

>> 

>> A question that remains: if you don’t want to transfer your ASN in or out of ARIN, then don’t, but why forbid others from doing 

>>it? All resources should be transferable.

> 

> We can agree to disagree.

I agree with Owen, I just can't see a burning need. Renumbering seems to be a bugaboo that is just not that difficult.

Even if you don’t see a need, would you want to preclude others from transferring their resource if they concluded it is a requirement for their business operation?

I would think the transfer of the ASN would as costly, difficult and risky as migrating the resources onto a new ASN.

I’m puzzled by your statement. Renumbering an ASN may involve operations on hundreds of routers and tens of thousands of BGP sessions - such renumbering clearly is costly and operationally risky.

Transferring a resource from one RIR to another RIR is paperwork between RIRs - no router changes. A transfer and a renumbering don’t seem comparable at all. Do you consider IPv4 transfers costly and risky too?

Kind regards,

Job

_______________________________________________

ARIN-PPML

You are receiving this message because you are subscribed to

the ARIN Public Policy Mailing List ( <mailto:ARIN-PPML at arin.net> ARIN-PPML at arin.net).

Unsubscribe or manage your mailing list subscription at:

 <https://lists.arin.net/mailman/listinfo/arin-ppml> https://lists.arin.net/mailman/listinfo/arin-ppml

Please contact  <mailto:info at arin.net> info at arin.net if you experience any issues.

_______________________________________________

ARIN-PPML 

You are receiving this message because you are subscribed to 

the ARIN Public Policy Mailing List ( <mailto:ARIN-PPML at arin.net> ARIN-PPML at arin.net). 

Unsubscribe or manage your mailing list subscription at: 

 <https://lists.arin.net/mailman/listinfo/arin-ppml> https://lists.arin.net/mailman/listinfo/arin-ppml 

Please contact  <mailto:info at arin.net> info at arin.net if you experience any issues. 

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ( <mailto:ARIN-PPML at arin.net> ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
 <https://lists.arin.net/mailman/listinfo/arin-ppml> https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact  <mailto:info at arin.net> info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180814/064fb4b1/attachment.htm>