[arin-ppml] 2-byte ASN policy

[David Huberman]

Thanks for the good reply, Job.

So two things.

1) It's a trade-off, right?  A network operator who absolutely must have a 2-byte either has equipment that hasn't been updated in 6+ years, or is having an issue like BGP communities where the solution they want to implement requires a 2-byte (rather than what Owen is talking about).  Their network, their rules.   So if they want a 2-byte, and ARIN has inventory of 2-bytes -- but they're found in the DFZ -- that requires the network operator to make a decision.

ARIN's lawyers can surely indemnify ARIN from any fault. So in this scenario (which Im just proposing as a thought experiment) the network operator should be allowed to determine for herself what's best for her network.

2) ARIN staff (me!) spent many years trying to get upstreams to help us deal with the backlog of ASNs which were (from a Registry perspective) being squatted on. And these arent published in Whois btw. But it was simply too much volume to handle.  The upstreams are primarily concerned with profit, and customer relations, and this was very much a low priority.  Then add in high volume for 7018 or someone like that, and it became completely untenable.    In your scenario, it's less volume.  But success in this path is not an expectation I would want to set for anyone who is fine taking a routed ASN.

Thanks
/david

________________________________________
From: Job Snijders <job at ntt.net>
Sent: Monday, April 4, 2016 5:17 PM
To: David Huberman
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] 2-byte ASN policy

On Mon, Apr 04, 2016 at 08:56:34PM +0000, David Huberman wrote:
> ARIN has traditionally had a large number of AS numbers (almost all
> 2-byte) in the "hold" bucket. These are ASNs which have been revoked
> for years due to non-payment and separation from the RSA.  But they're
> still found in the DFZ.
>
> Can't ARIN ask requestors who say they need 2-bytes if they'd be
> willing to accept a 2-byte ASN that may have route announcements
> present in the DFZ, and due to circumstances blah blah blah?  It boils
> down to "we have 2-byte ASNs, but they're not quite as clean as one
> might expect - is that ok?", because I'm pretty sure the answer will
> always be "HECK YEAH!"

> ASNs aren't quite like IP addresses in this context.  There's no
> conflict I know of unless the new registrants tries to directly
> exchange routes with the old registrant, which is mathematically
> highly improbable.

(Assuming at least one of two parties is running their network with
default settings..)

Indrect route exchange will also fail due to AS_PATH loop prevention.
("Phase 2: Route Selection" RFC4271).

The idea is interesting, but I wonder if there will be cases where the
new ASN holder just can't get the old ASN holder's peers & upstreams to
disconnect the illegitimately user of the ASN, causing operational
issues.

Kind regards,

Job