On (2014-04-30 18:30 +0100), James Blessing wrote: Hi James,
Other than the use cases suggested in the document (which could be achieved using private ASNs) is there a reason for this that I'm missing?
Without having public ASN, migrating from upstream X to upstream Y will be problematic. And as private ASN won't be distributed from your upstream, you cannot use communities to communicate with far-end system. So it won't be the same in every use-case. Also consider: customerLAN <eBGP> CE <eBGP> PE If CE is managed by same instance as PE, what ASN should you use for your CE? Every CE in whole network can use same ASN, but what ASN to use? If you choose privateASN, you can easily collidate with customerLAN and you cannot know what configuration to use beforehand, creating complexity (which reduces quality). Infact, this is not even change to a implicit policy, implicit policy shared by community today is, that having ASN without two upstream is justifiable and quite common. It's so common, RIPE does not even enforce the current policy in any way, since community would not want that. It's just about making the explicit policy match the implicit/practical policy. Few things I'm somewhat concerned of, but seem to be out-of-scope for this particular policy, but may require work in other places. a) should 16b ASN be special? You get GLOP/24 with it and you get BGP communities. Some use-cases absolutely depend on these, some use-cases don't. Is it realistic/possible to have different requirements for 16b and 32b? b) policy is quite (and was) soft is it possible to have hard policy? I define soft policy as abstract or approximate and open to interpretation, where as hard policy is exact and unambiguous. But hard policies seems nearly impossible, at least Finnish law always fails my definition of hard policy. And this policy also fails that. Hard policy would be for example one which does not have _any_ requirement on requesting and getting ASN, however that would lead to a situation where someone can request 32b of them, which could be made non-issue by having 1EUR YRC, but billing changes is out-of-scope. Right now, the policy stops hoarding with sentence 'cannot be satisfied with an existing or private AS Number.', which is soft, as it's interpreted by hostmaster, but it is in tradition of other RIPE policies. -- ++ytti