> On Feb 25, 2015, at 15:10 , David Farmer <farmer@umn.edu> wrote:
>
> On 2/25/15 15:44 , Dean Pemberton wrote:
> ...
>> There is essentially no barrier to entry here.  If a site needs an ASN
>> they are able to receive one.  If they want one 'just in case', then
>> that is against current policy and I'm ok with that.
>>
>> Dean
>
> From a policy perspective there is no barrier to entry.
>
> However, from an operational perspective, I see it a little differently; having deployed my network using a private ASN, I then need to migrate to a new unique registry assigned ASN.  Which you are saying I can't have until I've grown to the point were I need to multi-home or connect to an IX.  If I'm a small network, this may not be a big hardship.  But if you connect to a single provider in multiple cities you could build a fairly extensive network that would not qualify for a registry assigned ASN until you got a second provider or connected to an IX, at which point the transition to the new ASN could be rather complicated.

That’s actually not the case.

The case is until you choose to multihome or connect to an IX. You can choose to do that with a pretty small network. My home is multihomed, for example.

Any network with an IPv4 upstream can get an IPv6 tunnel from HE, turn on BGP, and poof, they are sufficiently multihomed for the APNIC definition. HE has several tunnel servers in the APNIC region to support this.

Changing ASNs on peering sessions actually isn’t very hard. There’s a brief period where you have inconsistent origin, but otherwise, it’s mostly one line of config change on each of your border routers. Even if you’ve got a hundred peering sessions, it’s something that can be done in a day or two with a cooperative provider. It might take a few weeks with some of the less responsive providers.

However, while I’m not trying to tell anyone how to run their network, I think we can agree that it is pretty foolhearty to get much beyond 2 or 3 peering sessions without mixing in some provider diversity. Further, if you want to plan ahead and deploy an ASN early, turning up an HE tunnel to do that is pretty easy. Unless HE is your only upstream for IPv4, you’re all set at that point.

> I'm not sure that justifies obliterating the current policy, but there is at least an operational barrier to entry in some situations.  I think maybe a compromise would be to allow a network of a certain size to obtain an ASN regardless of having a unique routing policy, being multi-homed, or connected to an IX.

I don’t think size is relevant. As I said, I wouldn’t oppose a policy modification that in addition to the current mechanisms, allowed for anyone with a PI allocation or assignment to obtain a single ASN without question.

> A network of 1 or 2 routers probably doesn't justify an ASN unless it is multi-homed or connected to an IX.  A network of 100 routers probably justifies an ASN regardless.  Then the question becomes, where to draw the line.

I’m having trouble envisioning who would build a network with 100 border routers (only the border routers really count in this case) without connecting to more than one upstream. This smells like looking for a corner case to justify a solution looking for a problem statement.


Owen


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