I agree. Perhaps the use cases were too narrow? I see (and practice) single homing on a wide scale and the efficiencies of doing it responsibly are valuable to big and small alike IMHO. I don't recall the proposal and didn't pay attention to it. Mea culpa. Best, -M< ________________________________________ From: David Huberman <David.Huberman@microsoft.com> Sent: Monday, November 9, 2015 11:57 AM To: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) As a community, I think it is important we resurrect this proposal as soon as possible. Requiring classic multi homing in order to obtain an AS Number is out of step with current engineering and operational practices. Can the authors, the chairs, the staff, or any knowledgeable observer please outline where the impasse is? I'd like to help get this back on the docket, but need to understand the bottom line. Thank you David David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________________ From: address-policy-wg <address-policy-wg-bounces@ripe.net> on behalf of Marco Schmidt <mschmidt@ripe.net> Sent: Monday, November 9, 2015 7:20:02 AM To: address-policy-wg@ripe.net Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) Dear colleagues, The proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has been withdrawn. It is now archived and can be found at: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ripe.net%2fparticipate%2fpolicies%2farchived-policy-proposals%2farchive-policy-proposals%2f&data=01%7c01%7cDAVID.HUBERMAN%40microsoft.com%7c06032ab2d4b940bc9e9108d2e919567e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=viQADY8DeLG%2fIyaMw6R62%2bJ5%2fVarFDLm4DFipQQcCT8%3d Reason for withdrawal: The proposers decided to withdraw the proposal due to the inability to find an acceptable solution which satisfied all parties. Regards, Marco Schmidt Policy Development Officer RIPE NCC

Thank you, ytti. So let's start with the basics. Does the following text allow the NCC to meet the needs of network operators today? "A new AS number is only assigned when the network architecture has a need that cannot be satisfied with an existing AS number." There will be more policy text. But again, let's start with -- and agree on -- the basics. Thanks! David David R Huberman Principal, Global IP Addressing Microsoft Corporation

I think that the pilot projects, testbeds or trainings are/could be already covered by the temporary assignments for which I think this proposal was not intended to change anything. I think that one 16bit ASN per LIR limit is not prudent as LIR != route end point, this notion that LIR is also "end customer" or the sole user of the network has been established in the last few years with the last /8 policy where I guess most of the new LIRs are actually also the route end point for their allocation, but if you look back LIRs were/are the middle-man between RIR and end customer which actually (could) need their own ASN so the need for the 16bit ASN exists at a third party and not directly with the LIR. I guess the need for 16bit ASN and with that requirements to get a 16bit ASN should stay unchanged but on the other hand the limitations for 32bit ASNs could be more relaxed. Uros On Tue, Nov 10, 2015 at 8:59 AM, Wilfried Woeber <Woeber@cc.univie.ac.at> wrote:

David Huberman wrote:

...

Thank you, ytti.

So let's start with the basics. Does the following text allow the NCC to meet the needs of network operators today?

"A new AS number is only assigned when the network architecture

I would be more edxplicit and more flexible here, by adding e.g.

or project

...

has a need that cannot be satisfied with an existing AS number."

Looking at SDN stuff and pilot projects or testbeds, or even trainings or workshops, I can see the need to interconnect such projects with the 'real' net and to use globally unique AS numbers.

I do understanf that "network architecture" can be interpreted as a rather wide and flexible term, but we should try to provide as good guidance as we can to support the evaluation of requests by the IPRAs.

Wilfried

...

There will be more policy text. But again, let's start with -- and agree on -- the basics.

Thanks! David

David R Huberman Principal, Global IP Addressing Microsoft Corporation

Hi, On Wed, Nov 11, 2015 at 09:55:26PM +0000, David Huberman wrote:

Very good input, thank you Wilfried!

Does anyone else have any suggestions or objections to:

"A new AS number is only assigned when the network architecture and/or project has a need that cannot be satisfied by an existing AS number."

If there are no objections to this part of the text, that gives the WG a good foundation to build on in Bucharest, in my opinion.

Just to play the devil's advocate, who is to evaluate and understand these "cannot be satisfied" reasons? RIPE IPRAs are typically not BGP experts. Not saying that this is not a good starting point, but we always need to keep in mind that there are good people at the NCC who need to evaluate these requests, and they might not all have the in-depth understanding of technology... Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

On 2015 Nov 12 (Thu) at 18:13:56 +0200 (+0200), Saku Ytti wrote: :On 12 November 2015 at 09:53, Gert Doering <gert@space.net> wrote: :> Just to play the devil's advocate, who is to evaluate and understand these :> "cannot be satisfied" reasons? RIPE IPRAs are typically not BGP experts. :> :> Not saying that this is not a good starting point, but we always need to :> keep in mind that there are good people at the NCC who need to evaluate :> these requests, and they might not all have the in-depth understanding :> of technology... : :You should be saying this. This is what we got from RIPE NCC trying to :pull it off. And I agree with them. If hostmasters need to decide, we :need to tell them what are the rules. i.e. w need to iterate :acceptable uses, which I don't want. I don't expect to know all use :cases. : :I say this, clearly arrogantly, I think correct approach is: : :a) 32b ASN, question asked in form, but not evaluated (just to educate :ourselves, why do people think they need ASNs) large limit per :organisation, like 1000 ASN per organisation (LIR fees are low enough :to justify buying another LIR if you need more ASN). :b) 16b ASN, must not be stub network, must transit someone (if we can :verify multihoming today, we can verify transiting tomorrow) : Thinking out loud: We could also apply the "last /8 policy" to this. After it goes into effect, each LIR can request one and only one 16b ASN. 32b ASNs are allocated as normal (with the question asked, but not evalutated). -- Maintainer's Motto: If we can't fix it, it ain't broke.

Hi, how would you explain it when a company (non-member) would ask why can a new LIR still receive a 16bit ASN and they can't? my 2 cents, elvis Excuse the briefness of this mail, it was sent from a mobile device. PS: apologies for the top-post

On Nov 13, 2015, at 00:46, Erik Bais <erik@bais.name> wrote:

Hi Peter,

...

Thinking out loud: We could also apply the "last /8 policy" to this. After it goes into effect, each LIR can request one and only one 16b ASN. 32b ASNs are allocated as normal (with the question asked, but not evalutated).

I think that we are already beyond the point of handing out 1* 16b ASn to each LIR and there isn't that much left in the free pool I'm guessing .. ( that is my gut feeling .. )

But the NCC should be able to answer the total number in the RIPE pool ...

Erik Bais

Hi, On Fri, Nov 13, 2015 at 11:02:07AM +0100, Christian Kratzer wrote:

The situaion is very similar to the last /8 situation and I would support extending the last /8 policy to 16 bit AS numbers as well.

Actually, it is totally different. LIRs are entities that handle address distribution, but not necessarily run a network (many do, some do not), so tieing "last /8 address space" to "one LIR one block" is a compromise that sort of follows what the LIR does: hand out address space. Now, AS numbers are much more tied to the structure of the network - who is running BGP, who is transitting other ASes or just a leaf node - and the model "one LIR = one transit autonomous system" totally doesn't hold - not even "one LIR = one autonomous system in BGP". For a leaf node, 32bit ASes work mostly well. For a transit network, not so much, for the reasons listed - but not every LIR is a transit network (or has plans to eventually become one). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

More flexible policy for better operation practice is really preferred in all cases. -Lu On Fri, Nov 13, 2015 at 11:48 AM, Radu-Adrian FEURDEAN < ripe-wgs@radu-adrian.feurdean.net> wrote:

On Fri, Nov 13, 2015, at 11:10, Gert Doering wrote:

...

On Fri, Nov 13, 2015 at 11:02:07AM +0100, Christian Kratzer wrote:

...

The situaion is very similar to the last /8 situation and I would support extending the last /8 policy to 16 bit AS numbers as well.

Actually, it is totally different. LIRs are entities that handle address distribution, but not necessarily run a network (many do, some do not), so tieing "last /8 address space" to "one LIR one block" is a compromise that sort of follows what the LIR does: hand out address space.

Not so much lately. At least not for new players and for the cases where a opening a LIR replaces a PI block. However, I do agree that some LIRs may not need an ASN at all, and most others may be fine with 32bit ASNs. Even for transit networks, 16-bit ASN is not a must in all cases.

I think needs evaluation, as ugly as it is, it's still the best way of not wasting limited ressoucres. And a good recovery policy (maybe including "forced recovery/deregistration for non-complicance") is even better.

Concerning the criteria for allocating a 16bit ASN, for a transit network I would add "accept 32bit ASN from customers", just to make sure. There are really ugly thing out there in the wild.

-- Radu-Adrian FEURDEAN fr.ccs

-- -- Kind regards. Lu

Dear colleagues, There are approximately 2,950 16-bit ASNs left in our pool, including the returned ASNs that are still referenced in other database objects. At the current rate of assignment, thepool of 16-bit ASNs will last 36 months. Within a few weeks, the RIPE NCC will start reassigning the referenced ASNs: https://www.ripe.net/manage-ips-and-asns/as-numbers/reassigning-as-numbers Best regards, Ingrid Wijte Assistant Manager Registration Services RIPE NCC On 13/11/2015 09:46, Erik Bais wrote:

Hi Peter,

...

Thinking out loud: We could also apply the "last /8 policy" to this. After it goes into effect, each LIR can request one and only one 16b ASN. 32b ASNs are allocated as normal (with the question asked, but not evalutated). I think that we are already beyond the point of handing out 1* 16b ASn to each LIR and there isn't that much left in the free pool I'm guessing .. ( that is my gut feeling .. )

But the NCC should be able to answer the total number in the RIPE pool ...

Erik Bais

Hi Saku,

Personally I'd go with the original proposal and limit ASN per organisation. I'd also like to solve 16b ASN shortage by limiting single 16b ASN to organisation who has downstream public ASNs (because communities are important for downstream to signal information to upstream).

Just for my understanding, is there any demand for 16b ASN from the community? By default you get 32b ASN unless there is compelling reason for 16b. IANA gave the last block last year to all RIRs so if the requirement is there then it should be single 16b ASN to new LIR and nothing to existing ones. I believe only handful 16b ASNs are left in each RIR (though NCC may clarify) -- Best Wishes, Aftab A. Siddiqui

On 2015 Nov 10 (Tue) at 04:30:22 +0000 (+0000), Aftab Siddiqui wrote: :Just for my understanding, is there any demand for 16b ASN from the :community? There is a technical case when attempting to use communities in the <as>:<as> format. There is not yet a 32:32b community available, even in extended communities. 16b:32b and 32b:16b do exist, so I'm not sure how critical that is. -- The bigger the theory the better.

Dear Peter and Aftab, Extended communities are not transported in the Internet. So if I start new company and I want to sell IP transit, I'm competitively in disadvantageous position if I cannot market <myASN>:<action> traffic engineering policies to my customers. Sure I can use privateASN (and I must), but they are clearly less preferable on INET, and almost certainly won't cross many links. I.e. 16b ASN is special and should be under more strict assignment policy, when living without BGP communities is hard. On 10 November 2015 at 11:49, Peter Hessler <phessler@theapt.org> wrote:

On 2015 Nov 10 (Tue) at 04:30:22 +0000 (+0000), Aftab Siddiqui wrote: :Just for my understanding, is there any demand for 16b ASN from the :community?

There is a technical case when attempting to use communities in the <as>:<as> format. There is not yet a 32:32b community available, even in extended communities. 16b:32b and 32b:16b do exist, so I'm not sure how critical that is.

-- The bigger the theory the better.

-- ++ytti

On 10 November 2015 at 14:37, Aftab Siddiqui <aftab.siddiqui@gmail.com> wrote:

Problem is the extremely low number of 16b ASN in the pool of every RIR. Although RIPE NCC has a quarantine policy (if am not mistaken) with 000+ ASN in it (NCC can confirm). Strict assignment policy would be great but BGP Communities can be simple justification to get 16b ASN and bypass any hurdles isn't it?

I would expect that anyone who gets 16b ASN transits some downstream. Otherwise it's hard to argue you need globally visible BGP communities. -- ++ytti

Why don’t you wish to talk to the Policy Development Officer? -- Kind regards, Sergey Myasoedov

On 11 Nov 2015, at 19:55, Aleksey Bulgakov <aleksbulgakov@gmail.com> wrote:

Hello.

Who can send the docs for new proposal creation?

10 нояб. 2015 г. 17:00 пользователь "Saku Ytti" <saku@ytti.fi> написал: On 10 November 2015 at 14:37, Aftab Siddiqui <aftab.siddiqui@gmail.com> wrote:

...

Problem is the extremely low number of 16b ASN in the pool of every RIR. Although RIPE NCC has a quarantine policy (if am not mistaken) with 000+ ASN in it (NCC can confirm). Strict assignment policy would be great but BGP Communities can be simple justification to get 16b ASN and bypass any hurdles isn't it?

I would expect that anyone who gets 16b ASN transits some downstream. Otherwise it's hard to argue you need globally visible BGP communities.

-- ++ytti