Re: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments)
Dear all, Thank you Marco for taking the time to review this policy proposal. Much appreciated. On Fri, Jul 11, 2014 at 10:21:11AM +0200, Marco Schmidt wrote:
The draft document for the proposal described in 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has been published. The impact analysis that was conducted for this proposal has also been published.
You can find the full proposal and the impact analysis at:
https://www.ripe.net/ripe/policies/proposals/2014-03
and the draft document at:
https://www.ripe.net/ripe/policies/proposals/2014-03/draft
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 11 August 2014.
Section A.1 of the impact analysis might seem counter-intuitive to some, especially given the title of this policy proposal. Section 2.0 of RIPE-525 (the current policy) states: "In order to help decrease global routing complexity, a new AS Number should be used only if a new external routing policy is required, see RFC1930." RFC1930 in turn lists some cases where an AS assigment is not needed, especially in context of single-homing. Marco, am I correct in assuming this reasoning has been followed? Section C: Regarding "Potential Future Multihoming", why does the RIPE NCC need "a time period allowed for multihoming"? Regarding validation of multi-homing: given the nature of BGP it is extremely hard to assess whether somebody is multi-homed or not. I would not expect the RIPE NCC to validate if somebody is multihomed, Relying on possibly forged "show bgp sum"'s runs counter to the spirit of the proposal: truth & accuracy are most important. Kind regards, Job
Dear Job,
Section C:
Regarding "Potential Future Multihoming", why does the RIPE NCC need "a time period allowed for multihoming"?
This concept of "Potential Future Multihoming" appears in the Rationale, part "a. Arguments supporting the proposal", second bullet point: "A network might not be multihomed today, but might want to prepare its infrastructure so it can multihome at a moment's notice, or have some form of mobility in terms of suppliers." My understanding is, and I think this is how the RIPE NCC interpreted it as well, that the requester may simply state that their network is expected to become multi-homed in the future, and this would be a good reason (i.e. one that the RIPE NCC should accept) for receiving an ASN. If there is no time limit when the requester is expected to become multi-homed, and/or the RIPE NCC is not expected to check this and ask for the ASN to be returned if the network is not multi-homed by that date, then I feel this part of the proposed policy is equivalent to saying that you simply have to ask for an ASN and the RIPE NCC must assign you one. Am I wrong? If this is how the policy proposal has to be interpreted, I do not support it. Best regards, Janos
Regarding validation of multi-homing: given the nature of BGP it is extremely hard to assess whether somebody is multi-homed or not. I would not expect the RIPE NCC to validate if somebody is multihomed, Relying on possibly forged "show bgp sum"'s runs counter to the spirit of the proposal: truth & accuracy are most important.
Kind regards,
Job
On 11 July 2014 15:20, Janos Zsako <zsako@iszt.hu> wrote: Hi Janos,
My understanding is, and I think this is how the RIPE NCC interpreted it as well, that the requester may simply state that their network is expected to become multi-homed in the future, and this would be a good reason (i.e. one that the RIPE NCC should accept) for receiving an ASN.
If there is no time limit when the requester is expected to become multi-homed, and/or the RIPE NCC is not expected to check this and ask for the ASN to be returned if the network is not multi-homed by that date, then I feel this part of the proposed policy is equivalent to saying that you simply have to ask for an ASN and the RIPE NCC must assign you one.
Am I wrong?
Yes. Option for multihoming easily does not imply it will ever happen, just that if need arises it's simple. Same goes for never having plans to multihome, but want to have easy, independent ability to switch providers on demand. You may also benefit from public ASN in scenarios where it's not even visible in the Internet (same goes for public IP addresses). Personally I would have wanted YRC to ASN and have no rules, lack of YRC make the policy soft and ambiguous, but I've bene told this is not a problem as many other RIPE policies are soft and ambiguous. In practice many RIPE members lie in ASN applications, because their use-case, which is commonly agreed to be valid, is not covered by current policy. This policy intends to align implied policy with written policy. I'd love to hear suggestion how to make it harder without YRC. Should there be strict list of valid use-cases? Should we expect RIPE NCC hostmasters to have understanding what is common/accepted use-case?
If this is how the policy proposal has to be interpreted, I do not support it.
-- ++ytti
* Job Snijders
Section A.1 of the impact analysis might seem counter-intuitive to some, especially given the title of this policy proposal.
Indeed. Considering the title of the proposal, and the fact the entire proposed new policy document has 0 occurrences of the word "multihoming", I can't wrap my head around how the IA could end up claiming that the requirement for multihoming is not removed.
Regarding "Potential Future Multihoming", why does the RIPE NCC need "a time period allowed for multihoming"?
Agreed. After all, the word used is "potential" - so it wouldn't be a certainty, but an eventuality. AIUI, in this case obtaining an ASN would be akin to obtaining insurance. Also I find it somewhat surprising that the NCC seems to require an exhaustive list of what all the valid uses of an ASN is. The NCC has, after all, for a very long time delegated IP addresses to folks that have a valid use for them - without there being any exhaustive list of valid technical justifications for IP addresses present in policy. In any case, the IA ends by mentioning the possibility of the NCC preparing a procedural document that lists the various justifications for ASNs that will be approved. I think this is a reasonable approach. The list could start out with containing 1) multihoming, 2) anything from RFC1930, and 3) any other example from 2014-03's supporting notes; and be amended as required based on light-weight consultation with the community/wg (as opposed to requiring full PDP cycles every time). Tore
On Sun, Jul 13, 2014 at 11:06 AM, Tore Anderson <tore@fud.no> wrote:
In any case, the IA ends by mentioning the possibility of the NCC preparing a procedural document that lists the various justifications for ASNs that will be approved. I think this is a reasonable approach. The list could start out with containing 1) multihoming, 2) anything from RFC1930, and 3) any other example from 2014-03's supporting notes; and be amended as required based on light-weight consultation with the community/wg (as opposed to requiring full PDP cycles every time).
Nice. Also, this would certainly make it easier for those who wonder what they should put in their request. -- Jan
participants (5)
-
Jan Ingvoldstad -
Janos Zsako -
Job Snijders -
Saku Ytti -
Tore Anderson