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

[WOOD Alison * DAS]

ARIN Community:

As we approach the next ARIN meeting, I would like to remind the community of the proposal to allow inter-regional ASN transfers. I will be presenting this topic at the meeting and would love to address any comments or questions on this proposal. Please feel free to email the PPML with your interest on this policy proposal.

Thank you!

-Alison Wood

[Owen DeLong]

I still feel this is a pony. A largely unnecessary solution looking for a tiny number of niche problems.

Owen


> On Aug 13, 2018, at 10:01, WOOD Alison * DAS <***@oregon.gov> wrote:
>
> ARIN Community:
>
> As we approach the next ARIN meeting, I would like to remind the community of the proposal to allow inter-regional ASN transfers. I will be presenting this topic at the meeting and would love to address any comments or questions on this proposal. Please feel free to email the PPML with your interest on this policy proposal.
>
> Thank you!
>
> -Alison Wood
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-***@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact ***@arin.net if you experience any issues.

[Job Snijders]

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.

Kind regards,

Job

[Owen DeLong]

> On Aug 13, 2018, at 14:42 , Job Snijders <***@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 remain of the opinion that the transfer of IPv4 resources was, for lack of a better term, a necessary evil to meet the expediencies of a (hopefully unusual) situation (namely the end of the IPv4 free pool prior to the ubiquitous deployment of IPv6).

Similarly to the mission creep of NAT (which was deployed for largely the same reason and which is now mistakenly widely perceived to be a security tool), transfers are now seeing this sort of mission creep.

Having been through several ASN renumbering processes, I found them neither particularly costly (compared to the other tasks related to the event triggering the need for the ASN renumber), nor operationally risky.

For the most part, networks themselves don’t move from one continent to another, so the need for migratory ASNs seems rather dubious in the vast majority of cases.

Owen

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

[Job Snijders]

On Tue, 14 Aug 2018 at 00:48, Owen DeLong <***@delong.com> wrote:

> > On Aug 13, 2018, at 14:42 , Job Snijders <***@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.



OK.

question still stands why anyone would object to others moving resources
around. From what I understand from the ARIN staff analysis, implementation
of this proposal is not a big deal.
https://www.arin.net/policy/proposals/2018_1.html


Having been through several ASN renumbering processes, I found them
> neither particularly costly (compared to the other tasks related to the
> event triggering the need for the ASN renumber), nor operationally risky.



Your positive experiences with renumbering ASNs don’t discount the negative
experiences that members of the community have observed.


For the most part, networks themselves don’t move from one continent to
> another, so the need for migratory ASNs seems rather dubious in the vast
> majority of cases.



An example, HQs sometimes move places. Your classification of “dubious” is
just an opinion.

Kind regards,

Job

[Larry Ash]

On Mon, 13 Aug 2018 14:47:09 -0700
Owen DeLong <***@delong.com> wrote:
>
>
>> On Aug 13, 2018, at 14:42 , Job Snijders <***@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.
I would think the transfer of the ASN would as costly, difficult and risky as migrating the resources onto a new ASN.

>
> I remain of the opinion that the transfer of IPv4 resources was, for lack of a better term, a necessary evil to meet the
>expediencies of a (hopefully unusual) situation (namely the end of the IPv4 free pool prior to the ubiquitous deployment of
>IPv6).
>
> Similarly to the mission creep of NAT (which was deployed for largely the same reason and which is now mistakenly widely
>perceived to be a security tool), transfers are now seeing this sort of mission creep.
>
> Having been through several ASN renumbering processes, I found them neither particularly costly (compared to the other tasks
>related to the event triggering the need for the ASN renumber), nor operationally risky.
>
>For the most part, networks themselves don’t move from one continent to another, so the need for migratory ASNs seems rather
>dubious in the vast majority of cases.
>
> Owen
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-***@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact ***@arin.net if you experience any issues.

Larry Ash
Mountain West Technologies
123 W 1st St.
Casper, WY 82601
Office 307 233-8387
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-***@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact ***@arin.net if you

[Job Snijders]

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

> On Mon, 13 Aug 2018 14:47:09 -0700
> Owen DeLong <***@delong.com> wrote:
> >> On Aug 13, 2018, at 14:42 , Job Snijders <***@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

[Scott Leibrand]

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 <***@ntt.net> wrote:

> On Tue, 14 Aug 2018 at 01:23, Larry Ash <***@mwtcorp.net> wrote:
>
>> On Mon, 13 Aug 2018 14:47:09 -0700
>> Owen DeLong <***@delong.com> wrote:
>> >> On Aug 13, 2018, at 14:42 , Job Snijders <***@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 (ARIN-***@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact ***@arin.net if you experience any issues.
>

[Steven Ryerse]

+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

[Description: Description: Eclipse Networks Logo_small.png]℠ Eclipse Networks, Inc.
Conquering Complex Networks℠

From: ARIN-PPML <arin-ppml-***@arin.net> On Behalf Of Scott Leibrand
Sent: Monday, August 13, 2018 6:52 PM
To: Job Snijders <***@ntt.net>
Cc: ARIN-PPML List <arin-***@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 <***@ntt.net<mailto:***@ntt.net>> wrote:
On Tue, 14 Aug 2018 at 01:23, Larry Ash <***@mwtcorp.net<mailto:***@mwtcorp.net>> wrote:
On Mon, 13 Aug 2018 14:47:09 -0700
Owen DeLong <***@delong.com<mailto:***@delong.com>> wrote:
>> On Aug 13, 2018, at 14:42 , Job Snijders <***@ntt.net<mailto:***@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 (ARIN-***@arin.net<mailto:ARIN-***@arin.net>).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact ***@arin.net<mailto:***@arin.net> if you experience any issues.

[Mike Burns]

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 <***@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   ℠ Eclipse Networks, Inc.         Conquering Complex Networks℠   From: ARIN-PPML <arin-ppml-***@arin.net> On Behalf Of Scott Leibrand Sent: Monday, August 13, 2018 6:52 PM To: Job Snijders <***@ntt.net> Cc: ARIN-PPML List <arin-***@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 <***@ntt.net> wrote: On Tue, 14 Aug 2018 at 01:23, Larry Ash <***@mwtcorp.net> wrote: On Mon, 13 Aug 2018 14:47:09 -0700   Owen DeLong <***@delong.com> wrote: >> On Aug 13, 2018, at 14:42 , Job Snijders <***@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 (ARIN-***@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact ***@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 (ARIN-***@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact ***@arin.net if you experience any issues.

[Owen DeLong]

Correction


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

Owen


> On Aug 13, 2018, at 16:03 , Mike Burns <***@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 <***@eclipse-networks.com <mailto:***@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 <arin-ppml-***@arin.net <mailto:arin-ppml-***@arin.net>> On Behalf Of Scott Leibrand
> Sent: Monday, August 13, 2018 6:52 PM
> To: Job Snijders <***@ntt.net <mailto:***@ntt.net>>
> Cc: ARIN-PPML List <arin-***@arin.net <mailto:arin-***@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 <***@ntt.net <mailto:***@ntt.net>> wrote:
> On Tue, 14 Aug 2018 at 01:23, Larry Ash <***@mwtcorp.net <mailto:***@mwtcorp.net>> wrote:
> On Mon, 13 Aug 2018 14:47:09 -0700
> Owen DeLong <***@delong.com <mailto:***@delong.com>> wrote:
> >> On Aug 13, 2018, at 14:42 , Job Snijders <***@ntt.net <mailto:***@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 (ARIN-***@arin.net <mailto:ARIN-***@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 ***@arin.net <mailto:***@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 (ARIN-***@arin.net <mailto:ARIN-***@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 ***@arin.net <mailto:***@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 (ARIN-***@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact ***@arin.net if you experience any issues.

[h***@uneedus.com]

+1 as to AS transfers.

I have no heartburn regarding this, and the existing unused policy tends
to show that this action is in fact quite rare and likely to be used only
when absolutely needed.

The only thing that I wish to express is that I do not want to ever see
IPv6 transfers, since the sparse assignment policies of IPv6 were designed
to control the bloat of the DFZ that is getting even worse under IPv4,
largely driven by splits and transfers of smaller and smaller blocks being
advertised in the DFZ. With the extreme size of the numbering space in
IPv6, versus IPv4 we need to keep these routes consolidated as much as
possible.

We have put up with transfers in IPv4 because of need. This need does not
exist in IPv6 at this time, and with the large numbers used need never
happen. Please, let go of the legacy issues in the newer IPv6 protocol.
While I may never see the retirement of IPv4, I can dream of the days
where obtaining numbering resources is no longer an issue, nor where
"hacks" like NAT and CIDR are needed because of lack of numbers, breaking
peer to peer connections.

Unlike in IPv4, there are actions that could be taken in IPv6 to expand
the available numbering in the event that we ever get anywhere close to
IPv6 exhaust. Among ideas I can think of would to deprecate the use of
SLAAC in future numbering blocks (for example the blocks beginning with
a-e), and allocating smaller in those last blocks. For example, instead
of a /32 per LIR, /48 per site, and a /64 per network as the "default",
reduce these values to /64, /80 and /96, using the local part to expand
the addresses available for assignment by an LIR by many orders of
magnitude. Many have already advanced getting rid of SLAAC for privacy and
security reasons, so it might not be missed once Android learns to do
DHCPv6 more universally. Android is the only real reason for SLAAC on many
current networks. I am sure that other similar ideas may be advanced in a
couple of centuries when this issue may need to be addressed.

Keeping away transfers in IPv6 will go far to reducing the DFZ growth.

Albert Erdmann
Network Administrator
Paradise On Line Inc.


On Mon, 13 Aug 2018, Owen DeLong wrote:

> Correction

>
> APNIC and RIPE already have policy to support this process with no utilization.
>
> Owen
>
>
>> On Aug 13, 2018, at 16:03 , Mike Burns <***@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 <***@eclipse-networks.com <mailto:***@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 <arin-ppml-***@arin.net <mailto:arin-ppml-***@arin.net>> On Behalf Of Scott Leibrand
>> Sent: Monday, August 13, 2018 6:52 PM
>> To: Job Snijders <***@ntt.net <mailto:***@ntt.net>>
>> Cc: ARIN-PPML List <arin-***@arin.net <mailto:arin-***@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 <***@ntt.net <mailto:***@ntt.net>> wrote:
>> On Tue, 14 Aug 2018 at 01:23, Larry Ash <***@mwtcorp.net <mailto:***@mwtcorp.net>> wrote:
>> On Mon, 13 Aug 2018 14:47:09 -0700
>> Owen DeLong <***@delong.com <mailto:***@delong.com>> wrote:
>>>> On Aug 13, 2018, at 14:42 , Job Snijders <***@ntt.net <mailto:***@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 (ARIN-***@arin.net <mailto:ARIN-***@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 ***@arin.net <mailto:***@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 (ARIN-***@arin.net <mailto:ARIN-***@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 ***@arin.net <mailto:***@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 (ARIN-***@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact ***@arin.net if you experience any issues.
>
>

[Jo Rhett]

"The only thing that I wish to express is that I do not want to ever see
IPv6 transfers"

I totally understand why someone would say this given a static marketplace,
but buyouts and mergers and sales of business units (partial buyouts) do
occur.

On Tue, Aug 14, 2018 at 12:01 AM <***@uneedus.com> wrote:

> +1 as to AS transfers.
>
> I have no heartburn regarding this, and the existing unused policy tends
> to show that this action is in fact quite rare and likely to be used only
> when absolutely needed.
>
> The only thing that I wish to express is that I do not want to ever see
> IPv6 transfers, since the sparse assignment policies of IPv6 were designed
> to control the bloat of the DFZ that is getting even worse under IPv4,
> largely driven by splits and transfers of smaller and smaller blocks being
> advertised in the DFZ. With the extreme size of the numbering space in
> IPv6, versus IPv4 we need to keep these routes consolidated as much as
> possible.
>
> We have put up with transfers in IPv4 because of need. This need does not
> exist in IPv6 at this time, and with the large numbers used need never
> happen. Please, let go of the legacy issues in the newer IPv6 protocol.
> While I may never see the retirement of IPv4, I can dream of the days
> where obtaining numbering resources is no longer an issue, nor where
> "hacks" like NAT and CIDR are needed because of lack of numbers, breaking
> peer to peer connections.
>
> Unlike in IPv4, there are actions that could be taken in IPv6 to expand
> the available numbering in the event that we ever get anywhere close to
> IPv6 exhaust. Among ideas I can think of would to deprecate the use of
> SLAAC in future numbering blocks (for example the blocks beginning with
> a-e), and allocating smaller in those last blocks. For example, instead
> of a /32 per LIR, /48 per site, and a /64 per network as the "default",
> reduce these values to /64, /80 and /96, using the local part to expand
> the addresses available for assignment by an LIR by many orders of
> magnitude. Many have already advanced getting rid of SLAAC for privacy and
> security reasons, so it might not be missed once Android learns to do
> DHCPv6 more universally. Android is the only real reason for SLAAC on many
> current networks. I am sure that other similar ideas may be advanced in a
> couple of centuries when this issue may need to be addressed.
>
> Keeping away transfers in IPv6 will go far to reducing the DFZ growth.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
>
> On Mon, 13 Aug 2018, Owen DeLong wrote:
>
> > Correction

> >
> > APNIC and RIPE already have policy to support this process with no
> utilization.
> >
> > Owen
> >
> >
> >> On Aug 13, 2018, at 16:03 , Mike Burns <***@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 <
> ***@eclipse-networks.com <mailto:***@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 <arin-ppml-***@arin.net <mailto:
> arin-ppml-***@arin.net>> On Behalf Of Scott Leibrand
> >> Sent: Monday, August 13, 2018 6:52 PM
> >> To: Job Snijders <***@ntt.net <mailto:***@ntt.net>>
> >> Cc: ARIN-PPML List <arin-***@arin.net <mailto:arin-***@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 <***@ntt.net <mailto:
> ***@ntt.net>> wrote:
> >> On Tue, 14 Aug 2018 at 01:23, Larry Ash <***@mwtcorp.net <mailto:
> ***@mwtcorp.net>> wrote:
> >> On Mon, 13 Aug 2018 14:47:09 -0700
> >> Owen DeLong <***@delong.com <mailto:***@delong.com>> wrote:
> >>>> On Aug 13, 2018, at 14:42 , Job Snijders <***@ntt.net <mailto:
> ***@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 (ARIN-***@arin.net <mailto:
> ARIN-***@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 ***@arin.net <mailto:***@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 (ARIN-***@arin.net <mailto:
> ARIN-***@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 ***@arin.net <mailto:***@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 (ARIN-***@arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> https://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact ***@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 (ARIN-***@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact ***@arin.net if you experience any issues.
>


--
Jo Rhett

[David Farmer]

On Thu, Aug 16, 2018 at 11:53 AM, Jo Rhett <***@netconsonance.com> wrote:

> "The only thing that I wish to express is that I do not want to ever see
> IPv6 transfers"
>
> I totally understand why someone would say this given a static
> marketplace, but buyouts and mergers and sales of business units (partial
> buyouts) do occur.
>
> On Tue, Aug 14, 2018 at 12:01 AM <***@uneedus.com> wrote:
>
>> +1 as to AS transfers.
>>
>> I have no heartburn regarding this, and the existing unused policy tends
>> to show that this action is in fact quite rare and likely to be used only
>> when absolutely needed.
>>
>> The only thing that I wish to express is that I do not want to ever see
>> IPv6 transfers, since the sparse assignment policies of IPv6 were
>> designed
>> to control the bloat of the DFZ that is getting even worse under IPv4,
>> largely driven by splits and transfers of smaller and smaller blocks
>> being
>> advertised in the DFZ. With the extreme size of the numbering space in
>> IPv6, versus IPv4 we need to keep these routes consolidated as much as
>> possible.
>>
>> We have put up with transfers in IPv4 because of need. This need does
>> not
>> exist in IPv6 at this time, and with the large numbers used need never
>> happen. Please, let go of the legacy issues in the newer IPv6 protocol.
>> While I may never see the retirement of IPv4, I can dream of the days
>> where obtaining numbering resources is no longer an issue, nor where
>> "hacks" like NAT and CIDR are needed because of lack of numbers, breaking
>> peer to peer connections.
>>
>> Unlike in IPv4, there are actions that could be taken in IPv6 to expand
>> the available numbering in the event that we ever get anywhere close to
>> IPv6 exhaust. Among ideas I can think of would to deprecate the use of
>> SLAAC in future numbering blocks (for example the blocks beginning with
>> a-e), and allocating smaller in those last blocks. For example, instead
>> of a /32 per LIR, /48 per site, and a /64 per network as the "default",
>> reduce these values to /64, /80 and /96, using the local part to expand
>> the addresses available for assignment by an LIR by many orders of
>> magnitude. Many have already advanced getting rid of SLAAC for privacy
>> and
>> security reasons, so it might not be missed once Android learns to do
>> DHCPv6 more universally. Android is the only real reason for SLAAC on
>> many
>> current networks. I am sure that other similar ideas may be advanced in a
>> couple of centuries when this issue may need to be addressed.
>>
>> Keeping away transfers in IPv6 will go far to reducing the DFZ growth.
>>
>> Albert Erdmann
>> Network Administrator
>> Paradise On Line Inc.
>>
>>
>> On Mon, 13 Aug 2018, Owen DeLong wrote:
>>
>> > Correction

>> >
>> > APNIC and RIPE already have policy to support this process with no
>> utilization.
>> >
>> > Owen
>> >
>> >
>> >> On Aug 13, 2018, at 16:03 , Mike Burns <***@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 <
>> ***@eclipse-networks.com <mailto:***@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 <arin-ppml-***@arin.net <mailto:arin-ppml-bounces@
>> arin.net>> On Behalf Of Scott Leibrand
>> >> Sent: Monday, August 13, 2018 6:52 PM
>> >> To: Job Snijders <***@ntt.net <mailto:***@ntt.net>>
>> >> Cc: ARIN-PPML List <arin-***@arin.net <mailto:arin-***@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 <***@ntt.net <mailto:
>> ***@ntt.net>> wrote:
>> >> On Tue, 14 Aug 2018 at 01:23, Larry Ash <***@mwtcorp.net <mailto:
>> ***@mwtcorp.net>> wrote:
>> >> On Mon, 13 Aug 2018 14:47:09 -0700
>> >> Owen DeLong <***@delong.com <mailto:***@delong.com>> wrote:
>> >>>> On Aug 13, 2018, at 14:42 , Job Snijders <***@ntt.net <mailto:
>> ***@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 (ARIN-***@arin.net <mailto:
>> ARIN-***@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 ***@arin.net <mailto:***@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 (ARIN-***@arin.net <mailto:
>> ARIN-***@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 ***@arin.net <mailto:***@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 (ARIN-***@arin.net).
>> >> Unsubscribe or manage your mailing list subscription at:
>> >> https://lists.arin.net/mailman/listinfo/arin-ppml
>> >> Please contact ***@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 (ARIN-***@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact ***@arin.net if you experience any issues.
>>
>
>
> --
> Jo Rhett
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-***@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact ***@arin.net if you experience any issues.
>
>


--
===============================================
David Farmer Email:***@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: [phone]
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================

[Mike Burns]

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 <***@delong.com>
Sent: Monday, August 13, 2018 7:05 PM
To: Mike Burns <***@iptrading.com>
Cc: Steven Ryerse <***@eclipse-networks.com>; ARIN-PPML List <arin-***@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 <***@iptrading.com <mailto:***@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:***@eclipse-networks.com> ***@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-***@arin.net> arin-ppml-***@arin.net> On Behalf Of Scott Leibrand

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

To: Job Snijders < <mailto:***@ntt.net> ***@ntt.net>

Cc: ARIN-PPML List < <mailto:arin-***@arin.net> arin-***@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:***@ntt.net> ***@ntt.net> wrote:

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

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

Owen DeLong < <mailto:***@delong.com> ***@delong.com> wrote:

>> On Aug 13, 2018, at 14:42 , Job Snijders < <mailto:***@ntt.net> ***@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-***@arin.net> ARIN-***@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:***@arin.net> ***@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-***@arin.net> ARIN-***@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:***@arin.net> ***@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-***@arin.net> ARIN-***@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:***@arin.net> ***@arin.net if you experience any issues.

[Owen DeLong]

> On Aug 13, 2018, at 15:52 , Scott Leibrand <***@gmail.com> wrote:
>
> 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.

Actually, if anything, on those peering sessions, one would need to prepend the new ASN and preserve the peering session with a peer-specific local-as configuration using the old one.

The last time I did this, it involved roughly 1,200 routers and about 75,000 peering sessions with a few thousand remote ASNs.

3 months in, we had 80% compliance from our peers. At the 6 month mark, we were up to 95% and after 12 months, we had, IIRC, one peer that hadn’t updated their configurations.

> 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.

Can anyone cite more than 3 examples where this is needed and/or has actually occurred?

The existing inter-regional ASN transfer policies have been exercised exactly 0 times since they were enacted.



> 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.

I’m not arguing “I’ve never needed to do that” or “I can’t imagine why
” I’m arguing “I’ve done it and it really isn’t as hard as some would have you believe.”

It’s certainly not operationally risky if you have competent people do it in a responsible way


1. Set up new peering session
2. Get remote peer to migrate to new peering session
3. Clean up old peering session

Lather, rinse, repeat.

Multiple peers can easily be done in parallel.

Actually, none of you have detailed the kind of organization or provided actual examples. Instead, you have hypothesized that such organizations exist and insisted that the community just accept that.

Owen

>
> -Scott
>
> On Mon, Aug 13, 2018 at 3:36 PM Job Snijders <***@ntt.net <mailto:***@ntt.net>> wrote:
> On Tue, 14 Aug 2018 at 01:23, Larry Ash <***@mwtcorp.net <mailto:***@mwtcorp.net>> wrote:
> On Mon, 13 Aug 2018 14:47:09 -0700
> Owen DeLong <***@delong.com <mailto:***@delong.com>> wrote:
> >> On Aug 13, 2018, at 14:42 , Job Snijders <***@ntt.net <mailto:***@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 (ARIN-***@arin.net <mailto:ARIN-***@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 ***@arin.net <mailto:***@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 (ARIN-***@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact ***@arin.net if you experience any issues.

[Carlton Samuels]

I can support this. No harm, no foul.

Associating traffic with one organisation regardless of geographic location
is actually of interest. I know of one Caribbean entity that is thinking
this thru in respect of outposts that could be established in the Pacific.

-Carlton

==============================
*Carlton A Samuels*

*Mobile: [phone]Strategy, Process, Governance, Assessment & Turnaround*
=============================


On Mon, Aug 13, 2018 at 12:02 PM WOOD Alison * DAS <***@oregon.gov>
wrote:

> ARIN Community:
>
>
>
> As we approach the next ARIN meeting, I would like to remind the community
> of the proposal to allow inter-regional ASN transfers. I will be
> presenting this topic at the meeting and would love to address any comments
> or questions on this proposal. Please feel free to email the PPML with
> your interest on this policy proposal.
>
>
>
> Thank you!
>
>
>
> -Alison Wood
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-***@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact ***@arin.net if you experience any issues.
>

[Peter Harrison]

Agreed Carlton,

Quite apart from the technical consideration, this would also allow
accounting departments to consolidate some of their A/P vendor lists. The
lack of usage of the feature could be due to the fact that these teams are
unaware of the possibility.



Peter

---

Peter Harrison
CTO, Colovore LLC


On Thu, Aug 16, 2018 at 10:02 AM, Carlton Samuels <***@gmail.com
> wrote:

> I can support this. No harm, no foul.
>
> Associating traffic with one organisation regardless of geographic
> location is actually of interest. I know of one Caribbean entity that is
> thinking this thru in respect of outposts that could be established in the
> Pacific.
>
> -Carlton
>
> ==============================
> *Carlton A Samuels*
>
> *Mobile: [phone]Strategy, Process, Governance, Assessment &
> Turnaround*
> =============================
>
>
> On Mon, Aug 13, 2018 at 12:02 PM WOOD Alison * DAS <***@oregon.gov>
> wrote:
>
>> ARIN Community:
>>
>>
>>
>> As we approach the next ARIN meeting, I would like to remind the
>> community of the proposal to allow inter-regional ASN transfers. I will be
>> presenting this topic at the meeting and would love to address any comments
>> or questions on this proposal. Please feel free to email the PPML with
>> your interest on this policy proposal.
>>
>>
>>
>> Thank you!
>>
>>
>>
>> -Alison Wood
>> _______________________________________________
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-***@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact ***@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 (ARIN-***@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact ***@arin.net if you experience any issues.
>
>

[Brian Jones]

While I do not see the burning need for this, evidence suggests that it does occur, therefore a policy to cover it seems appropriate. I support this policy.

--
Brian E Jones, CSP-SM, CSP-PO
NI&S Virginia Tech
***@vt.edu

> On Aug 13, 2018, at 1:01 PM, WOOD Alison * DAS <***@oregon.gov> wrote:
>
> ARIN Community:
>
> As we approach the next ARIN meeting, I would like to remind the community of the proposal to allow inter-regional ASN transfers. I will be presenting this topic at the meeting and would love to address any comments or questions on this proposal. Please feel free to email the PPML with your interest on this policy proposal.
>
> Thank you!
>
> -Alison Wood
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-***@arin.net <mailto:ARIN-***@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 ***@arin.net <mailto:***@arin.net> if you experience any issues.

[Mike Arbrouet]

I will support policy.

Mike Arbrouet

------ Original message------
From: Brian Jones
Date: Thu, Aug 16, 2018 1:16 PM
To: arin-***@arin.net;
Cc:
Subject:Re: [arin-ppml] ARIN-2018-1: Allow Inter-regional ASN Transfers

While I do not see the burning need for this, evidence suggests that it does occur, therefore a policy to cover it seems appropriate. I support this policy.

--
Brian E Jones, CSP-SM, CSP-PO
NI&S Virginia Tech
***@vt.edu<mailto:***@vt.edu>

On Aug 13, 2018, at 1:01 PM, WOOD Alison * DAS <***@oregon.gov<mailto:***@oregon.gov>> wrote:

ARIN Community:

As we approach the next ARIN meeting, I would like to remind the community of the proposal to allow inter-regional ASN transfers. I will be presenting this topic at the meeting and would love to address any comments or questions on this proposal. Please feel free to email the PPML with your interest on this policy proposal.

Thank you!

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