[Apwg-ipv6-papi] [pdo] last changes?
Daniel Stolpe
stolpe at resilans.se
Mon Sep 16 15:11:29 CEST 2013
Hi Elvis,
I think option #1 will be easiest to get acceptance in the community so if
that is what we aim for it is probably a good idea to start there. We
could of course mention the possibility reviewing this issue again in due
time. Maybe after six months or a year.
The summary looks fine.
Cheers,
Daniel
On Mon, 16 Sep 2013, Elvis Velea wrote:
> Hi Olaf,
>
> great to know that we are on the same page :)
>
> I'm waiting for Daniel's decision before I change the proposal text again, if
> he also agrees with Option #1, we will have:
>
> - RIPE NCC allocates by default a /32
> - if LIR requests, up to a /29 can be allocated with no further justification
> needed
> - LIR can request more than a /29 by providing justification
> - EU can request more than a /32 by providing justification
>
> LIR or EU sub-allocates up to a /48 with no request needed
> - LIR can sub-allocate more than a /48 to themselves, an EU or End Site but
> approval is needed from the RIPE NCC
> - EU can sub-allocate more than a /48 to themselves, an EU or End Site but
> they must submit a request for approval via the Sponsoring LIR
> - some exceptions in 5.3.5 (should we keep it?)
>
> cheers,
> elvis
>
> On 9/16/13 2:41 PM, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
>> Dear all
>>
>> Option #1 is okay for me. I wanted to clarify it, before we open
>> discussion for the whole community.
>>
>> Q1 / Q2: End Users need a relationship (contract, ...) with a Sponsoring
>> LIR. In my opinion, if an End User request anything, it has to be
>> processed by Sponsoring LIR. Sponsoring LIR could realize some kind of
>> business with End User, that's why Sponsoring LIR should also do the work
>> (on behalf of End User). Section 2.4 "Sponsoring LIR" defines, that
>> Sponsoring LIR have to "facilitate the administrative processes". In my
>> opinion, it's everything defined.
>>
>> Cheers, Olaf
>>
>>
>> -----Original Message-----
>> From: Elvis Velea [mailto:elvis at velea.eu]
>> Sent: Montag, 16. September 2013 12:59
>> To: Marco Schmidt
>> Cc: Daniel Stolpe; Sonderegger Olaf ABRAXAS INFORMATIK AG; Sander
>> Steffann; Gert Doering; Ingrid Wijte; Andrea Cima; apwg-ipv6-papi at ripe.net
>> Subject: Re: [Apwg-ipv6-papi] [pdo] last changes?
>>
>> 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
_________________________________________________________________________________
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
More information about the Apwg-ipv6-papi
mailing list