[Apwg-ipv6-papi] [pdo] last changes?

Elvis Velea elvis at velea.eu
Mon Sep 16 12:59:18 CEST 2013 

Good morning everyone,
(it was still morning when I started writing this message)

(an other long email incoming, if you do not have time to read all of 
it, see the last paragraph with my proposed solution)

We still have a few decisions to make regarding what kind of requests 
should the RIPE NCC evaluate (excepting the initial/additional 
allocation request) and who can send these requests.

A bit of background.. just as Marco said, the RIPE NCC has received a 
handful of requests for assignments to End Sites larger than /48.
Out of these requests, only one was actually a request for one single 
End Site that justified need for more than a /48, the rest were requests 
for multiple End Sites of the same customer or requests where the need 
for more than a /48 was not justified.


Now, since we are removing the differences between Assignment and 
Sub-Allocation, we may want to revisit this idea.

How can the RIPE NCC/LIR/EU differentiate between an EU that has more 
than one End Site and needs a /47 (let's say 2x/48s for their 2 sites) 
and an EU that only has one End Site and needs one /47?
- we did remove the idea of the Assignment from the policy and that 
makes the evaluation of these a bit more difficult.

One solution would be - the RIPE NCC evaluates all requests for 
sub-allocation for any EU or End Site that needs more than a /48. This 
may create a bit of work for the RIPE NCC and limit what the LIR or the 
EU can do without RIPE NCC approval.

A second solution would be to limit the size of the sub-allocation (with 
no need for RIPE NCC approval) to an arbitrary number, let's say a /40. 
I don't think I've ever seen any request for an customer that needed 
more than a /40.

A third solution would be to clearly show in the RIPE Database objects 
that these two or more sub-allocations are for different End Sites of 
the same customer, but that means that we will let the LIR/EU to decide 
how to add this information in the RIPE Database objects.

A fourth solution would be to completely remove the need for a request 
and allow the LIR/EU to sub-allocate as much as they want to an EU or 
End Site. However, this may lead to cases where an LIR/EU sub-allocates 
a /33 to a customer (EU or End Site) and qualifies for an additional 
allocation immediately.

I think that as this policy proposal is already changing everything in 
IPv6, we should be a bit cautious on what we allow and what not. That is 
why I would vote for option #1 and see how it works for a year or two. 
If this creates too much workload for the LIR or the RIPE NCC, we could 
in the future modify the policy (if this proposal is accepted) to be a 
bit more liberal.


A second question that I had in my mind this past weekend is:

Q1: currently the RIPE NCC accepts requests from LIRs (and only from 
LIRs) for assignments made out of their allocation.

By allowing EUs to sub-allocate address space, we may see cases where an 
EU needs to send a request to request approval of a /47 sub-allocation. 
There is no clear process defined on this situation.
Additionally, in the current version we are allowing LIRs to make 
sub-allocations of up to a /32 and any sub-allocation made by an LIR 
that is larger than a /32 must be approved by the RIPE NCC.

Q2: What do we do with EUs that want/need to sub-allocate a /32 or 
larger? How can the EU send any request to the RIPE NCC? ( maybe via the 
Sponsoring LIR?)


I think that all the above questions could be solved by:

- making it mandatory that any sub-allocation larger than a /48 to be 
approved by the RIPE NCC (even for a customer with multiple End Sites)
- asking the RIPE NCC to evaluate requests from EU if these are sent by 
the Sponsoring LIR.

(at least for a while, to see if this creates overload of work and if it 
does, revisit the IPv6 policy and make it less restrictive)


What do you all think?

cheers,
elvis

On 9/16/13 11:43 AM, Marco Schmidt wrote:
> Hello,
>
> I had a look in your latest changes and it looks good so far.
>
> Regarding OIaf's and Daniels comment please see my answer below:
>
>
> On 9/16/13 11:04 AM, Daniel Stolpe wrote:
>>
>> Now we seem to have lost the list. I put it back in the CC again.
>>
>> On Mon, 16 Sep 2013, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
>>
>>> Dear Elvis
>>>
>>> Thanks a lot for your editing. I started a similar definition of End
>>> User, but a friend had an emergency, and he was took to the hospital.
>>>
>>> Updated version is nearby its final stage. I found only one last point.
>>>
>>>
>>> Marco started a discussion about section 5.3 last time:
>>> ---
>>> 5.3 Sub-allocations Shorter Than a /48 to a Single End Site
>>> When a single End Site requires a sub-allocation shorter than a /48,
>>> it must request the sub-allocation with documentation or materials
>>> that justify the request.  Requests for multiple or additional
>>> prefixes exceeding a /48 sub-allocation for a single End Site must be
>>> evaluated and by the RIPE NCC.
>>> ---
>>> I think, an evaluation of sub-allocations for End Sites aren't
>>> necessary. If a LIR or an EU distributes its allocations in a manner,
>>> that it run out of addresses, RIPE NCC could reject LIR's/EU's
>>> additional allocation request. I know, this way is more reactive than
>>> proactive. But otherwise, RIPE NCC has to evaluates a lot of request,
>>> which want be necessary.
>>>
>>> Could you shortly explain, what was your initial idea with this section?
>>
>> Looks lika heritage from the old ways? I can agree that if you waste
>> to many addresses in the same place it could be a better way to make
>> life harder the next time you ask for more space, rather than having
>> the NCC look at each sub-allocation immediately.
>>
>> I like the idea of delegated responsibility. Request with
>> documentation yes, but it can stay att LIR level until the next NCC
>> audit. I guess that was your point Olaf?
>>
> If you would remove that section then the RIPE NCC would have no base to
> reject additional allocation requests. Because there would be nothing in
> the policy to restrict an LIR/EU to sub-allocate for example 1000x /48's
> or a /38 to one customer - and this customer could be your grandmother
> in her little house ;)
> Maybe I've chosen an extreme example but just to show that this would be
> an easy way to reach the HD-ratio - and then on what ground the RIPE NCC
> can discuss that an LIR/EU can not give several /48's to one end site?
>
>
> Already now we only would evaluate such request if somebody really
> estimate to connect more than 65K hosts in a subnet (so far only one
> time a University managed to justify that).
> Most of the cases we get such requests when in reality an end user need
> more than a /48 because he has several end sites or customers - and then
> we recommend to assign a /48 per end site or use the status
> AGGREGATED-BY-LIR
>
>
> Regarding your proposal I just would like to stress again that I would
> need the confirmation from *all* proposer to the final version.
>
>
> Kind regards,
> Marco
>
>>
>>> -----Original Message-----
>>> From: Elvis Velea [mailto:elvis at velea.eu]
>>> Sent: Samstag, 14. September 2013 17:23
>>> To: Sander Steffann; Gert Doering; Ingrid Wijte; Andrea Cima;
>>> Sonderegger Olaf ABRAXAS INFORMATIK AG; Daniel Stolpe; Marco Schmidt
>>> Subject: Fwd: Re: [Apwg-ipv6-papi] [pdo] last changes?
>>>
>>> Hi,
>>>
>>> the message below needs moderator approval on the [Apwg-ipv6-papi] as
>>> it was too large due to the attached doc.
>>> "Message body is too big: 254011 bytes with a limit of 40 KB"
>>>
>>> Therefore, I'm sending it to everyone subscribed to that list :)
>>>
>>> cheers,
>>> elvis
>>>
>>> -------- Original Message --------
>>> Subject: Re: [Apwg-ipv6-papi] [pdo]     last changes?
>>> Date: Sat, 14 Sep 2013 17:13:18 +0200
>>> From: Elvis Velea <elvis at velea.eu>
>>> Reply-To: elvis at velea.eu
>>> To: Sonderegger Olaf ABRAXAS INFORMATIK AG <Olaf.Sonderegger at abraxas.ch>
>>> CC: Daniel Stolpe <stolpe at resilans.se>, "pdo at ripe.net"
>>> <pdo at ripe.net>, Marco Schmidt <mschmidt at ripe.net>,
>>> "apwg-ipv6-papi at ripe.net"
>>> <apwg-ipv6-papi at ripe.net>
>>>
>>> Hi everyone,
>>>
>>> again, sorry for the lack of presence in the past few days. I have
>>> been very busy setting up various procedures in our company.
>>>
>>> @Olaf - sorry I did not reply to the e-mail from the 11th..
>>>
>>> I managed to find a few hours today and worked on the document taking
>>> into account all your ideas :)
>>>
>>> I my mind I had the following:
>>> - remove the idea of portable addresses, allocations are allocations.
>>> - remove the crazy idea of PIR, not sure what I was smoking that day :)
>>> - define the EU
>>> - re-define the End Site
>>>
>>> Changes:
>>> - added 2.5 End User (EU) definition
>>> - updated 2.6 - End Site definition
>>> - moved 5.3 (Allocations made by the RIR) to 5.0 (I think it adds a
>>> bit more structure to the policy this way)
>>> - updated 5.1.2 to clarify what is the initial allocation size for
>>> LIR and for the EU
>>> - updated 5.1.3 and 5.1.4 (removed the idea of portable allocation)
>>> - updated "LIR's customer" with EU in various places
>>> - clarified where we use IR, LIR, EU or End Site
>>>
>>> I'm hoping that this time the update turned out quite good.
>>>
>>> The document is attached.
>>>
>>> cheers,
>>> elvis
>>>
>>> On 9/11/13 1:02 PM, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
>>>> Dear Daniel, Dear Elvis
>>>>
>>>> I could edit file while I travel home by train.
>>>>
>>>> Should I take the last document from Marco? Or did you change
>>>> everything on Google Drive?
>>>>
>>>> Cheers, Olaf
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Daniel Stolpe [mailto:stolpe at resilans.se]
>>>> Sent: Mittwoch, 11. September 2013 12:53
>>>> To: Elvis Velea
>>>> Cc: Sonderegger Olaf ABRAXAS INFORMATIK AG; pdo at ripe.net; Marco
>>>> Schmidt; apwg-ipv6-papi at ripe.net
>>>> Subject: Re: [Apwg-ipv6-papi] [pdo] last changes?
>>>>
>>>>
>>>> I'm currently not sure about what time I might have. Probably not
>>>> very much unfortunatly.
>>>>
>>>> On Tue, 10 Sep 2013, Elvis Velea wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> ok, introducing a new term gave a heart attack to Gert.. that usually
>>>>> means it's a bad idea ;)
>>>>>
>>>>> I will read the feedback each of you has provided and will come back
>>>>> with a revised document ;)
>>>>>
>>>>> However, these days I am very very busy, so I am not sure I will be
>>>>> able to find time to revise it by Friday.. I will try as much as I
>>>>> can.
>>>>>
>>>>> I like the definitions from Marco, can we add him to the list of
>>>>> proposers ? (joke)
>>>>>
>>>>> If any of you has time by Friday to work on these changes, let me
>>>>> know..
>>>>>
>>>>> If not, I'll try on Friday or during the weekend to come up with the
>>>>> last (this time I mean it) version.
>>>>>
>>>>> cheers,
>>>>> elvis
>>>>>
>>>>> On 9/10/13 2:48 PM, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
>>>>>> Hi all
>>>>>>
>>>>>>> 1)
>>>>>>> Definition "End User (EU)" with a clear demarcation to "End
>>>>>>> Site". End users are the organisations that can receive
>>>>>>> sub-allocations or portable allocations. End sites are LIRs and
>>>>>>> EU locations of local networks/customers (like in your graph
>>>>>>> section 2).
>>>>>>
>>>>>> +1, that's a good proposal and a better way.
>>>>>>
>>>>>>> 2)
>>>>>>> So why not simply write "LIR and EU" when something applies for
>>>>>>> both, and only "LIR" or "EU" if something applies only for one type?
>>>>>>
>>>>>> +1, that's also a good idea.
>>>>>>
>>>>>> What are you meaning, Elvis?
>>>>>>
>>>>>> Cheers, Olaf
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: apwg-ipv6-papi-bounces at ripe.net
>>>>>> [mailto:apwg-ipv6-papi-bounces at ripe.net] On Behalf Of Marco Schmidt
>>>>>> Sent: Dienstag, 10. September 2013 10:17
>>>>>> To: Gert Doering
>>>>>> Cc: pdo at ripe.net; apwg-ipv6-papi at ripe.net
>>>>>> Subject: Re: [Apwg-ipv6-papi] [pdo] last changes?
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> First of all I think the topics that you discuss are too relevant
>>>>>> to just implement them on the fly. The risk of inconsistencies in
>>>>>> the proposal is just too big.
>>>>>>
>>>>>> Also I checked with the webmasters and they need some time to
>>>>>> re-do all the pages, especially the policy text. They need to have
>>>>>> enough notification time to schedule their work as their are also
>>>>>> busy with all the upcoming meetings (MENOG, ENOG, RIPE).
>>>
>>>>>>
>>>>>>
>>>>>> May I propose the following:
>>>>>>
>>>>>> - the proposal gets back to you, you all agree what to edit and then
>>>>>> send the final version back to the RIPE NCC
>>>>>> - if you wish Comms make another review of the changes
>>>>>> - our webmaster get the final version and can set up everything and
>>>>>> then we publish :)
>>>>>>
>>>>>> If you agree during this week on the final version I think it is
>>>>>> realistic that we can publish (early) next week. Then the
>>>>>> discussion phase would end perfectly timed during the RIPE meeting.
>>>>>>
>>>>>>
>>>>>> I believe the following two issues spotted by you should be solved
>>>>>> before publishing:
>>>>>>
>>>>>> 1)
>>>>>> Definition "End User (EU)" with a clear demarcation to "End Site".
>>>>>> End users are the organisations that can receive sub-allocations
>>>>>> or portable allocations. End sites are LIRs and EU locations of
>>>>>> local networks/customers (like in your graph section 2).
>>>>
>>>>>>
>>>>>> 2)
>>>>>> Currently "IR" is often used when it should read "LIRs and End Users"
>>>>>> (for example in section 5) which could lead to confusion as one hand
>>>>>> RIRs are also IRs and on the other hand it is not clear that EUs are
>>>>>> IRs (and should they actually always seen as Internet Registry?)
>>>>>>
>>>>>> As Gert mentioned it might be too much to introduce now also new
>>>>>> terms in this policy proposal (you will change the IPv6 world
>>>>>> anyhow ;-) ).
>>>>>>
>>>>>> So why not simply write "LIR and EU" when something applies for
>>>>>> both, and only "LIR" or "EU" if something applies only for one type?
>>>>>>
>>>>>>
>>>>>> If you choose this way then we can keep the biggest part of the
>>>>>> current version, only extended by a more clear EU definition and
>>>>>> replace "IR"
>>>>>> where it is applicable.
>>>>>>
>>>>>> This would be my practical approach.
>>>>>> (for example Comms only would need to review the EU definition)
>>>>>>
>>>>>> But again, you have the last word as this is your baby :)
>>>>>>
>>>>>>
>>>>>> I've attached you the latest reviewed proposal version again. Do all
>>>>>> the changes you would like to do and agree on it. Then you send me
>>>>>> your final version back.
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Marco
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 9/9/13 9:38 PM, Gert Doering wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Mon, Sep 09, 2013 at 05:20:53PM +0200, Elvis Velea wrote:
>>>>>>>> Introducing the PIR - Portable Internet Registry \o/
>>>>>>> Uh, what?
>>>>>>>
>>>>>>> And - no, let's not go there.  RIR and LIR are well-defined terms
>>>>>>> and well-understood, introducing something that sounds similar
>>>>>>> enough to be confused with it while not being part of the "IR
>>>>>>> tree structure"
>>>>>>> would need quite a few *good* arguments to convince me.
>>>>>>>
>>>>>>>> @Marco, please ask Comms to update the following:
>>>>>>>>
>>>>>>>> - add
>>>>>>>>
>>>>>>>> 2.5 Portable Internet Registry (PIR)
>>>>>>>>
>>>>>>>> A Portable Internet Registry is an IR which can request (via a
>>>>>>>> Sponsoring LIR) a portable allocation from the RIR. The PIR
>>>>>>>> sub-allocates address space to the users of the network services
>>>>>>>> that it provides.
>>>>>>> If I have anything to say here, please let's *not* do that.
>>>>>>>
>>>>>>> Also, I think we should not use the term "IR" for "something that
>>>>>>> acts like a LIR but is not".
>>>>>>>
>>>>>>>
>>>>>>> Also, where is "portable allocation" coming from?  All allocations
>>>>>>> are "portable", by definition...
>>>>>>>
>>>>>>> Gert Doering
>>>>>>>            -- APWG chair
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Apwg-ipv6-papi mailing list
>>>>>> Apwg-ipv6-papi at ripe.net
>>>>>> https://www.ripe.net/mailman/listinfo/apwg-ipv6-papi
>>>>>>
>>>>>
>>>>> --
>>>>> Kind regards, Elvis Velea
>>>>>
>>>>> _______________________________________________
>>>>> Apwg-ipv6-papi mailing list
>>>>> Apwg-ipv6-papi at ripe.net
>>>>> https://www.ripe.net/mailman/listinfo/apwg-ipv6-papi
>>>>>
>>>>>
>>>>
>>>> mvh
>>>>
>>>> Daniel Stolpe
>>>>
>>>> _________________________________________________________________________________
>>>>
>>>> Daniel Stolpe           Tel:  08 - 688 11 81 stolpe at resilans.se
>>>> Resilans AB             Fax:  08 - 55 00 21 63 http://www.resilans.se/
>>>> Box 13 054                                  556741-1193
>>>> 103 02 Stockholm
>>>>
>>>
>>>
>>
>> mvh
>>
>> Daniel Stolpe
>>
>> _________________________________________________________________________________
>>
>> Daniel Stolpe           Tel:  08 - 688 11 81 stolpe at resilans.se
>> Resilans AB             Fax:  08 - 55 00 21 63 http://www.resilans.se/
>> Box 13 054                                  556741-1193
>> 103 02 Stockholm
>>
>

-- 
Kind regards, Elvis Velea

More information about the Apwg-ipv6-papi mailing list