[address-policy-wg] 2014-03 two cents on multi homing ASN requirement

Hi Job, 

As stated to you offlist, I support the idea of the proposal, but I can't disagree with the NCC review of how the current proposal is written. 

I think a lot of the discussion can be removed by changing the word MUST into a SHOULD in section 2.0 of ripe-525 

Personally I don't think the NCC should go further into asking if a requestor has considered the use of a private AS, but shouldn't enforce or question the motives of someone not to want to use a private AS. 

I can imagine that there are operational use cases for requesting a unique ASn without someone going full multi-homing at implementation. 

I rather have someone register for a AS instead of picking some random number which might lead to other issues globally or lie tot the NCC in order to obtain one. 

I trust the  NCC to monitor abuse of the intended policy on actual impact, which will allow more than sufficient time to change the charging scheme if needed in the future to bite guys like Nick in the .....  ;-) 

Regards,
Erik Bais 



Verstuurd vanaf mijn iPad

> Op 16 aug. 2014 om 13:31 heeft Job Snijders <job at instituut.net> het volgende geschreven:
> 
> Dear all,
> 
> Based on the feedback from the working group we have developed a
> new iteration of the proposal.
> 
> Concerns addressed:
> 
> - remove private AS Number reference (Fredy Kuenzler, 1 May 2014; Alex
>    le Heux, offlist; Erik Bais, offlist)
> - differentiate between 16 and 32 bit ASN (Nick Hilliard, 1 May 2014;
>    Aleksi Suhonen, 14 August 2014; RIPE NCC Impact analysis section B
>    "Autonomous System Number (ASN) Consumption")
> - Specify timeline when multihoming is required (Janos Zsako, 11 Jul 2014
> 
> What has not been addressed is the creation of an exhaustive list of
> acceptable reasons to request an ASN. The authors do not know how to
> update (without full PDP process) the list when new technologies or
> methodologies arise. Rather, the authors believe that RIPE NCC is
> responsible for maintaining an accurate registry than evaluate network
> designs. In a years time the RIPE NCC could publish an aggregated report
> on the recorded needs, possibly to inspire the community to reconsider
> this policy.
> 
> ----------------- replaces section 2.0 from RIPE-525 -----------------
> 2.0 Assignment Criteria
> 
> A new AS Number should only be assigned when the End User expresses a need
> that cannot be satisfied with an existing AS Number. RIPE NCC will record,
> but not evaluate this need.
> 
> When requesting a 16 bit AS Number, the network must be multihomed using
> the assigned AS Number within 6 months. A 32 bit AS Number is exempt from
> the multihoming requirement.
> 
> When requesting an AS Number, the routing policy of the Autonomous System
> must be provided. The new unique routing policy should be defined in RPSL
> language, as used in the RIPE Database.
> 
> The RIPE NCC will assign the AS Number directly to the End User upon a
> request properly submitted to the RIPE NCC either directly or through a
> sponsoring LIR. AS Number assignments are subject to the policies described
> in the RIPE Document “Contractual Requirements for Provider Independent
> Resource Holders in the RIPE NCC Service Region”.
> ------------------------------------------------------------------------
> 
> Kind regards,
> 
> Job & Ytti
>