Owen, Can't you see the fault in your argument? You are suggesting that a member needlessly creates a tunnel to HE just to satisfy the needs of the current policy... that seems wasteful and a stupid hoop which just gets around the policy.
I might as well just offer free peering with a couple of routes to my ASN for anyone who wants to satisfy the policy. The point here is fixing a requirement that is so easily avoided, it needed be there in the first place. All you are doing is causing people to create route-object garbage so that they are able to run their networks the way they want to. ...Skeeve *Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service [email protected] ; www.v4now.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4now ; <http://twitter.com/networkceoau> linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com IP Address Brokering - Introducing sellers and buyers On Thu, Feb 26, 2015 at 8:26 AM, Owen DeLong <[email protected]> wrote: > > > On Feb 25, 2015, at 15:10 , David Farmer <[email protected]> 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 > [email protected] > http://mailman.apnic.net/mailman/listinfo/sig-policy >
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
