[address-policy-wg] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments)

On (2014-04-30 18:30 +0100), James Blessing wrote:

Hi James,

> >     https://www.ripe.net/ripe/policies/proposals/2014-03
> 
> 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