Re: [address-policy-wg] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments)
On 30 April 2014 14:28, Marco Schmidt <mschmidt@ripe.net> wrote:
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? With other discussions about recovering non globally routed ASNs this just seem odd J -- James Blessing 07989 039 476
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
First, I'd like to say that I support the proposal. On Thu, May 1, 2014 at 12:10 PM, Saku Ytti <saku@ytti.fi> wrote:
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.
I like the soft policy. I think that if there are signs that someone starts hoarding, RIPE NCC would notify the community about the issue and request that we consider a policy for that, or perhaps someone outside the NCC would notice and create their own policy proposal. Until then, it is unnecessary to do anything in particular about it, except think about it and be prepared for this eventuality. -- Jan
Hi, I'm writing to provide some information and am neither speaking for or against the proposal. Saku Ytti wrote: [...]
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?
I should probably point out that there are other sources of IPv4 multicast address space if this is a consideration. Firstly, there are the Unicast-Prefix-Based IPv4 Multicast Addresses, which are assigned algorithmically. Every IPv4 /24 prefix gives the user a /32 multicast address from 234/8. If a network operator does not have GLOP or Unicast-Prefix-Based IPv4 Multicast Addresses, or has used all those addresses, then it also possible to request an assignment (https://www.iana.org/form/multicast-ipv4). There is no charge for multicast address assignments and there's no immediate danger of running out of multicast space to assign. Kind regards, Leo Vegoda
On 01/05/2014 11:10, Saku Ytti wrote:
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?
running an ASN32 leaf network is fine, otherwise it's a bit tragic due to community pain. Would probably not be a bad idea to differentiate between asn16 and asn32 until we see a functional bgp community spec widely available which is fully asn32 compatible. Nick
participants (5)
-
James Blessing -
Jan Ingvoldstad -
Leo Vegoda -
Nick Hilliard -
Saku Ytti