> On Feb 24, 2015, at 22:46 , Skeeve Stevens <ske...@v4now.com> wrote: > > To me, relaxing these rules is less about lying - although is easy, but it is > to do with flexibility. > > I understand the routing policy wont be different that an upstream without > being multi-homed, but it does curtail the convenience of being able to add > these things easily. > > Lets say I was a company with a /23 and upstream into Telstra Only. If I had > my own ASN and was announcing to Telstra, then at any time I could add > another ISP, IXP, direct peering without having to go apply for an ASN, > reconfigure my network to bring the announcement in-house, etc.
No you can’t… You just have already done it instead of doing it when you get ready to actually multihome. It’s all the same effort, just a difference in when you have to apply said effort. > I also might want to maintain a single provider, but be able to migrate > easily to another provider without having to rely on the providers to do the > "right thing" while changing announcements between them. This has some validity, but if you have an overlap period, you’re multihomed during the overlap and eligible for an ASN as a result. > I think this policy has VERY valid applications for many smaller entities to > be able to have an ASN without having to be multi-homed either initially, or > maintain that multi-homing. I don’t believe you lose your ASN if you stop multihoming. > As Randy used to say - Why do you have the right to tell me how to manage my > network? If I want to be multi-homed, or change my mind and not be, it is > none of your damn business. That’s true. But nobody is trying to tell you that. I don’t believe the APNIC policy calls for reclaiming ASNs from entities that are no longer multihomed. It merely prevents issuing ASNs to entities that are not multihomed. The only possible case I can see where this might be useful would be the case of two uplinks to the same ASN that are sufficiently topologically diverse as to make it desirable to do route injection for better failover capabilities. > I think this policy change reflects the changing way for businesses to get > online since APNIC has run out of IP's, and are often charging significant > amounts of money - so people are going to APNIC directly - which they are > entitled to do. And being flexible and being able to change their > circumstances is a more common thing nowadays. No, this policy change turns APNIC into an ASN pez dispenser which is an undesirable state. You don’t need an ASN to use provider independent addresses, so the rest of the paragraph is a red herring. The flexibility exists. It’s just a question of when one does the work to turn on BGP and get an ASN. I see no reason the community should hand out ASNs to anyone who thinks they might want one for some possible use at some possible time in some possible future. > If you want, suggest charging for ASN's... but don't tell networks how they > should be connected at any time. Nobody is telling anyone how they should be connected. This is about resource management of a community resource pool, not about dictating operational practice. You can do everything you have said you want to do with your network under the existing policy. You just can’t get an ASN until you actually need one. Imagine where we’d be if we had handed out all the IPv4 space to anyone who thought they might need some someday? > Btw... I am happy for this to apply ONLY to ASN4 and not ASN2. There are no more ASN4s than there are IPv4 addresses. 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
