From emadaio at ripe.net Tue Sep 6 11:16:33 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 06 Sep 2011 11:16:33 +0200 Subject: [address-policy-wg] 2011-01 Last Call for Comments (Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA) Message-ID: Dear Colleagues, The proposal described in 2011-01, "Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA", is now at its Concluding Phase. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2011-01/ Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 4 October 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC From t.schallar at avalon.at Wed Sep 7 11:05:29 2011 From: t.schallar at avalon.at (DI. Thomas Schallar) Date: Wed, 07 Sep 2011 11:05:29 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <4E574955.2040505@avalon.at> Message-ID: <4E6733D9.1050708@avalon.at> Hello! I was more interested about the TIMEFRAME one could expect. :-) The current status "Awaiting Decision from Working Group Chair" is two weeks old now (August 23rd). Please don't get me wrong: I am completely unfamiliar with RIPE decision findigs. I just like to know, how soon one can expect a decision - to finaly decide about that matter or to continue discussion again. regards, Thomas Marco Hogewoning schrieb am 26.08.2011 10:18: > On Aug 26, 2011, at 9:20 AM, DI. Thomas Schallar wrote: > > >> Hello! >> >> I'm back with the same question I made a month ago: what ist the current status on the multihomed v6 PI topic? The "current" phase on the proposal ended three days ago (August 23rd) and the status is "Awaiting Decision from Working Group Chair". >> >> http://www.ripe.net/ripe/policies/proposals/2011-02 >> >> What now? >> >> regards, >> Thomas >> > > The current state is what it says, it is awaiting a decision from the WG chair(s) together with the proposer on how to move forward. This decision is based on the feedback received on the mailing list during the last round. Usually this can go two ways: > > - There is rough consensus on the proposal and the suggested text, which will mean the proposal can move to last call > - People have suggested changes which need to be included or there seem to be a need for further discussion, in which case the current period will be extended or revised documents will be published together with a new call for feedback > > More information on the Policy Development Process, including all the phases can be found at http://www.ripe.net/ripe/policies/policy-development-process-glossary and is described in document ripe-500 which can be found in the document store at http://www.ripe.net/ripe/docs/ripe-500 > > Regards, > > Marco > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Wed Sep 7 12:07:51 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 7 Sep 2011 12:07:51 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <4E6733D9.1050708@avalon.at> References: <4E2FF96A.2000802@avalon.at> <4E574955.2040505@avalon.at> <4E6733D9.1050708@avalon.at> Message-ID: <002401cc6d46$01862a90$04927fb0$@com> Hi Thomas, I just called one of the AP WG chairs and gave him a gentle nudge on the topic. I?m pretty sure they will get back to us on this pretty soon. ( My guess is within 2 weeks.) Erik From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of DI. Thomas Schallar Sent: Wednesday, September 07, 2011 11:05 AM To: RIPE Address Policy Working Group Subject: Re: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? Hello! I was more interested about the TIMEFRAME one could expect. :-) The current status "Awaiting Decision from Working Group Chair" is two weeks old now (August 23rd). Please don't get me wrong: I am completely unfamiliar with RIPE decision findigs. I just like to know, how soon one can expect a decision - to finaly decide about that matter or to continue discussion again. regards, Thomas Marco Hogewoning schrieb am 26.08.2011 10:18: On Aug 26, 2011, at 9:20 AM, DI. Thomas Schallar wrote: Hello! I'm back with the same question I made a month ago: what ist the current status on the multihomed v6 PI topic? The "current" phase on the proposal ended three days ago (August 23rd) and the status is "Awaiting Decision from Working Group Chair". http://www.ripe.net/ripe/policies/proposals/2011-02 What now? regards, Thomas The current state is what it says, it is awaiting a decision from the WG chair(s) together with the proposer on how to move forward. This decision is based on the feedback received on the mailing list during the last round. Usually this can go two ways: - There is rough consensus on the proposal and the suggested text, which will mean the proposal can move to last call - People have suggested changes which need to be included or there seem to be a need for further discussion, in which case the current period will be extended or revised documents will be published together with a new call for feedback More information on the Policy Development Process, including all the phases can be found at http://www.ripe.net/ripe/policies/policy-development-process-glossary and is described in document ripe-500 which can be found in the document store at http://www.ripe.net/ripe/docs/ripe-500 Regards, Marco _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3882 - Release Date: 09/07/11 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Wed Sep 7 12:30:55 2011 From: sander at steffann.nl (Sander Steffann) Date: Wed, 7 Sep 2011 12:30:55 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <002401cc6d46$01862a90$04927fb0$@com> References: <4E2FF96A.2000802@avalon.at> <4E574955.2040505@avalon.at> <4E6733D9.1050708@avalon.at> <002401cc6d46$01862a90$04927fb0$@com> Message-ID: <0E1DD8A8-C246-48AF-9ABC-826EF16789A3@steffann.nl> Hi Erik, > I just called one of the AP WG chairs and gave him a gentle nudge on the topic. > > I?m pretty sure they will get back to us on this pretty soon. ( My guess is within 2 weeks.) Nudge received :-) We are still going through the whole mailing list archive to see which concerns were raised and how they were addressed. Quite a lot of messages were sent about this proposal over the last months! We're working on it. - Sander APWG co-chair -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From sm+afrinic at elandsys.com Mon Sep 19 09:07:57 2011 From: sm+afrinic at elandsys.com (S Moonesamy) Date: Mon, 19 Sep 2011 00:07:57 -0700 Subject: [address-policy-wg] IANA implementation analysis of proposal 2011-01, "Global Policy Proposal for Post Exhaustion IPv4 Allocation Mechanisms by IANA" In-Reply-To: <4E3BEB48.40703@ripe.net> References: <4E3BEB48.40703@ripe.net> Message-ID: <6.2.5.6.2.20110918223655.0a15f0a0@resistor.net> At 06:08 05-08-2011, Emilio Madaio wrote: >In order to provide a more comprehensive overview of the expected >implementation aspects of proposal 2011-01, the RIPE NCC sought input >from IANA staff. > >Below is the analysis produced by Leo Vegoda. We hope that this input >will be useful to RIPE community discussion of this proposal. [snip] >IANA staff impact analysis of RIPE policy proposal 2011-01 > >This analysis considers the impact of ratification of RIPE policy >proposal 2011-01 (as a part of GPP-IPv4-2011) by the ICANN Board of Directors. > >1. The policy would require ICANN, as the IANA function operator, to >establish a Recovered IPv4 Pool. The pool would have to include "any >fragments that may be left over in the IANA". In order to do this, >ICANN staff would have to work closely with the five RIRs' staffs to >make sure the initial pool included all fragments assigned to IANA. >It is not clear whether this policy proposal is intended to >supersede the IETF's right to make IPv4 assignments for "specialised >address blocks (such as multicast or anycast blocks)" as documented >in section 4.3 of RFC 2860. This should be clarified but that can >probably be done by way of assertions from the NRO rather than a >revision to the policy text. In the event that the policy is >intended to supersede RFC 2860 there is a potential issue with the >internal reservation of small blocks address blocks that have been >informally reserved for IETF standards track work currently in progress. The authors of proposal 2011-01 (GPP-IPv4-2011) do not intend to take over the IETF's role in assigning internet resources. The IANA Staff analysis asks for an assertion from the NRO instead of a revision to the policy text. During discussions with the ARIN Advisory Council, it was mentioned that the clarification requires a text change to the proposal. It was also mentioned that the ASO, instead of the NRO, must provide the clarification. To avoid any doubt, the authors of the proposal would appreciate if the ASO or the NRO, whichever is the appropriate party, can clarify that. Regards, S. Moonesamy From maildanrl at googlemail.com Mon Sep 19 12:30:49 2011 From: maildanrl at googlemail.com (Dan Luedtke) Date: Mon, 19 Sep 2011 12:30:49 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <0E1DD8A8-C246-48AF-9ABC-826EF16789A3@steffann.nl> References: <4E2FF96A.2000802@avalon.at> <4E574955.2040505@avalon.at> <4E6733D9.1050708@avalon.at> <002401cc6d46$01862a90$04927fb0$@com> <0E1DD8A8-C246-48AF-9ABC-826EF16789A3@steffann.nl> Message-ID: > Nudge received :-) ?We are still going through the whole mailing list archive to see which concerns were raised and how they were addressed. Quite a lot of messages were sent about this proposal over the last months! We're working on it. Good to hear that. I (as many other IPv4 PI "owners") can't wait to geht my IPv6 PI. regards, Dan -- danrl / Dan Luedtke http://www.danrl.de From emadaio at ripe.net Tue Sep 20 20:19:34 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 20 Sep 2011 20:19:34 +0200 Subject: [address-policy-wg] Updated RIPE document ripe-527, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" Message-ID: <4E78D936.3060301@ripe.net> Dear colleagues, Please note that ripe-524 has been updated to ripe-527. This is due to the addition of a sentence to the policy text. The sentence was accidentally removed from the policy text during the update that followed approval of policy proposal 2010-01. It has been reinstated in this version. This sentence is from the end of Section 11.0: "Information on training courses and training material can be found at: http://www.ripe.net/lir-services/training" The updated RIPE document is available at: https://www.ripe.net/ripe/docs/ripe-527 We apologise for this administrative oversight and any inconvenience caused. Kind regards, Emilio Madaio Policy Development Officer RIPE NCC From sander at steffann.nl Fri Sep 23 14:15:32 2011 From: sander at steffann.nl (Sander Steffann) Date: Fri, 23 Sep 2011 14:15:32 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call Message-ID: Hello working group, After a extensive analysis of the discussions on the mailing list about proposal 2011-02 we have come to the conclusion that we have rough consensus on this policy proposal, and we have decided to move this policy proposal to Last Call. We have seen much support for this proposal on the mailing list. On the other hand we have seen concern about accelerated growth of the routing table caused by implementing this policy. Data from other RIRs that have a more liberal IPv6 PI policy have not shown evidence for excessive growth in IPv6 PI assignments. As of today, Sep 23, there are 2420 /48 routes in the global BGP table, compared to 3600 /32 routes and ~1100 routes of other prefix lengths. Based on this data we consider the arguments agains this proposal based on possible routing table growth as addressed. We will ask the RIPE NCC to ask for extensive documentation in the IPv6 PI request form about why IPv6 PI space is requested instead of PA space. The intention of this is to be able to analyze the reasons for organizations to request PI space and to make requesters think twice when requesting PI space. If this policy proposal has consensus at the end of Last Call we will also ask the RIPE NCC to monitor and regularly report on IPv6 PI assignment statistics so we can see if the number of PI requests runs out of bounds. On behalf of the Address Policy WG chairs, Sander Steffann -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From davidm at futureinquestion.net Fri Sep 23 14:43:44 2011 From: davidm at futureinquestion.net (David Monosov) Date: Fri, 23 Sep 2011 14:43:44 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: Message-ID: <4E7C7F00.3050209@futureinquestion.net> Dear address-policy-wg, Sander, I'm glad to hear that a rough consensus has been achieved, and would like to reaffirm my support for this policy proposal. -- Respectfully yours, David Monosov On 09/23/2011 02:15 PM, Sander Steffann wrote: > Hello working group, > > After a extensive analysis of the discussions on the mailing list about proposal 2011-02 we have come to the conclusion that we have rough consensus on this policy proposal, and we have decided to move this policy proposal to Last Call. > > We have seen much support for this proposal on the mailing list. On the other hand we have seen concern about accelerated growth of the routing table caused by implementing this policy. Data from other RIRs that have a more liberal IPv6 PI policy have not shown evidence for excessive growth in IPv6 PI assignments. As of today, Sep 23, there are 2420 /48 routes in the global BGP table, compared to 3600 /32 routes and ~1100 routes of other prefix lengths. Based on this data we consider the arguments agains this proposal based on possible routing table growth as addressed. We will ask the RIPE NCC to ask for extensive documentation in the IPv6 PI request form about why IPv6 PI space is requested instead of PA space. The intention of this is to be able to analyze the reasons for organizations to request PI space and to make requesters think twice when requesting PI space. If this policy proposal has consensus at the end of Last Call we will also ask the RIPE NCC to monitor and regularly report on IPv6 PI assignment statistics so we can see if the number of PI requests runs out of bounds. > > On behalf of the Address Policy WG chairs, > Sander Steffann > From sander at steffann.nl Fri Sep 23 15:24:57 2011 From: sander at steffann.nl (Sander Steffann) Date: Fri, 23 Sep 2011 15:24:57 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <4E7C8696.2030102@inex.ie> References: <4E7C8696.2030102@inex.ie> Message-ID: Hi Nick, >> addressed. We will ask the RIPE NCC to ask for extensive documentation >> in the IPv6 PI request form about why IPv6 PI space is requested instead >> of PA space. > > I didn't see this mentioned in the policy proposal. Could you explain how > this requirement was reached in a way which is compatible with the RIPE > Policy Development Process - i.e. by consensus and in a transparent manner? Someone suggested to include such documentation in IPv6 PI requests. Because this is not actually a policy change (it doesn't change if someone gets the address space or not) but an implementation issue we decided to add it as a note to the RIPE NCC. - Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From nick at inex.ie Fri Sep 23 15:31:18 2011 From: nick at inex.ie (Nick Hilliard) Date: Fri, 23 Sep 2011 14:31:18 +0100 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C8696.2030102@inex.ie> Message-ID: <4E7C8A26.30104@inex.ie> On 23/09/2011 14:24, Sander Steffann wrote: > Someone suggested to include such documentation in IPv6 PI requests. > Because this is not actually a policy change (it doesn't change if > someone gets the address space or not) but an implementation issue we > decided to add it as a note to the RIPE NCC. I certainly suggested it as a policy possibility: > http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00820.html Not sure if others talked about it too. However, there is a substantial difference between "explicitly required to provide evidence" and "to ask for extensive documentation" - the former was suggested because it does materially change the policy. Nick From sander at steffann.nl Fri Sep 23 15:38:21 2011 From: sander at steffann.nl (Sander Steffann) Date: Fri, 23 Sep 2011 15:38:21 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <4E7C8A26.30104@inex.ie> References: <4E7C8696.2030102@inex.ie> <4E7C8A26.30104@inex.ie> Message-ID: <7889B02D-0A81-45E6-9454-A74C871A4069@steffann.nl> Hello Nick, >> Someone suggested to include such documentation in IPv6 PI requests. >> Because this is not actually a policy change (it doesn't change if >> someone gets the address space or not) but an implementation issue we >> decided to add it as a note to the RIPE NCC. > > I certainly suggested it as a policy possibility: > >> http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00820.html > > Not sure if others talked about it too. > > However, there is a substantial difference between "explicitly required to > provide evidence" and "to ask for extensive documentation" - the former was > suggested because it does materially change the policy. I know, but that would change the IPv6 PI policy into a judgement call by an IPRA. That would make the policy unimplementable. The information would still be interesting though, which is why I suggest to the RIPE NCC that they ask for it anyway. It's just a suggestion. We don't tell the NCC how to implement policy, but we can suggest :-) Thanks, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From nick at inex.ie Fri Sep 23 15:16:06 2011 From: nick at inex.ie (Nick Hilliard) Date: Fri, 23 Sep 2011 14:16:06 +0100 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: Message-ID: <4E7C8696.2030102@inex.ie> On 23/09/2011 13:15, Sander Steffann wrote: > addressed. We will ask the RIPE NCC to ask for extensive documentation > in the IPv6 PI request form about why IPv6 PI space is requested instead > of PA space. Sander, I didn't see this mentioned in the policy proposal. Could you explain how this requirement was reached in a way which is compatible with the RIPE Policy Development Process - i.e. by consensus and in a transparent manner? Nick From lists-ripe at c4inet.net Fri Sep 23 16:00:52 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Fri, 23 Sep 2011 14:00:52 +0000 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: Message-ID: <20110923140052.GA41839@cilantro.c4inet.net> On Fri, Sep 23, 2011 at 02:15:32PM +0200, Sander Steffann wrote: > We will ask the RIPE NCC to ask for extensive documentation in > the IPv6 PI request form about why IPv6 PI space is requested > instead of PA space. This requirement, completely negates the intent of the policy change. While it benefits a small amount of applicants (non-multihomed PIv6), it adds an unreasonable administrative burden on every other PIv6 applicant. I thus withdraw my support for this change unless the "extensive documentation" requirement is removed. rgds, Sascha Luck From nick at inex.ie Fri Sep 23 16:07:25 2011 From: nick at inex.ie (Nick Hilliard) Date: Fri, 23 Sep 2011 15:07:25 +0100 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <7889B02D-0A81-45E6-9454-A74C871A4069@steffann.nl> References: <4E7C8696.2030102@inex.ie> <4E7C8A26.30104@inex.ie> <7889B02D-0A81-45E6-9454-A74C871A4069@steffann.nl> Message-ID: <4E7C929D.2020901@inex.ie> On 23/09/2011 14:38, Sander Steffann wrote: > I know, but that would change the IPv6 PI policy into a judgement call > by an IPRA. That would make the policy unimplementable. The information > would still be interesting though, which is why I suggest to the RIPE > NCC that they ask for it anyway. It's just a suggestion. We don't tell > the NCC how to implement policy, but we can suggest :-) I admit that drawing the line between policy and implementation is a difficult issue, and that there are tensions between the two requirements. On the one hand, IPRAs get quite vague policies from ap-wg and would often like more clarity because they have a job to do and interpreting policy can sometimes be difficult. On the other hand, ap-wg tends to prefer to prescribe general principles and let the IPRAs do what seems sensible because they don't always have a clear picture of exactly the sort of requests that the IPRAs have to deal with. Hey, you can't legislate for every eventuality. Enough philosophy. There are two things that concern me here: 1. in this situation, I made a suggestion to add something to the policy and the proposers didn't put it into the policy and that's fine (I'm not hung up on 2011-02 and really want to see some form of IPv6 PI appear soon, and I'm particularly not hung up on the suggestion I made). However, someone blinked and now it's implicitly a part of the policy even though it wasn't part of the policy before. 2. if interpretation is implicitly added to a policy without it being explicitly stated, then the APWG is creating an expectation that the RIPE NCC will listen to this interpretation. I don't agree that it's just a suggestion: if there was no expectation that the NCC wasn't going to listen to it, the suggestion wouldn't have been made in the first place. Look, I really don't want to make this sound like bureaucratic ant abuse, but something has effectively been added to the policy outside the terms of the PDP and there is a problem with this. This is not a 2011-02 problem, but a PDP problem. Let's go ahead with 2011-02 as originally stated in the policy proposal - without the extra interpretation. Nick From sander at steffann.nl Fri Sep 23 16:11:35 2011 From: sander at steffann.nl (Sander Steffann) Date: Fri, 23 Sep 2011 16:11:35 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <20110923140052.GA41839@cilantro.c4inet.net> References: <20110923140052.GA41839@cilantro.c4inet.net> Message-ID: <4A558500-BEFE-4613-9E6F-DA4423769E93@steffann.nl> Hi Sasha, > I thus withdraw my support for this change unless the "extensive > documentation" requirement is removed. This is not part of the policy but a suggestion to the RIPE NCC. It seemed useful information to have, but if people think it is not then we won't suggest this to the NCC. However, all of this is part of the implementation (which is up to the NCC) and not part of the policy. The policy hasn't changed. Considering that this well-intended suggestion to the NCC seems to have caused controversy and distract from the actual policy proposal we will not send the suggestion to the NCC. - Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From sander at steffann.nl Fri Sep 23 16:12:46 2011 From: sander at steffann.nl (Sander Steffann) Date: Fri, 23 Sep 2011 16:12:46 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <4E7C929D.2020901@inex.ie> References: <4E7C8696.2030102@inex.ie> <4E7C8A26.30104@inex.ie> <7889B02D-0A81-45E6-9454-A74C871A4069@steffann.nl> <4E7C929D.2020901@inex.ie> Message-ID: <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> > Let's go ahead with 2011-02 as originally stated in the policy proposal - > without the extra interpretation. Agreed, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From Jasper.Jans at espritxb.nl Fri Sep 23 16:19:26 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Fri, 23 Sep 2011 16:19:26 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <4A558500-BEFE-4613-9E6F-DA4423769E93@steffann.nl> References: <20110923140052.GA41839@cilantro.c4inet.net> <4A558500-BEFE-4613-9E6F-DA4423769E93@steffann.nl> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD20104664BCF73@EXCH01.campus.local> > This is not part of the policy but a suggestion to the RIPE NCC. It seemed useful information to have, > but if people think it is not then we won't suggest this to the NCC. However, all of this is part of the > implementation (which is up to the NCC) and not part of the policy. The policy hasn't changed. > > Considering that this well-intended suggestion to the NCC seems to have caused controversy and distract > from the actual policy proposal we will not send the suggestion to the NCC. I support the policy under the terms stated above. Jasper Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From slz at baycix.de Fri Sep 23 16:26:59 2011 From: slz at baycix.de (Sascha Lenz) Date: Fri, 23 Sep 2011 16:26:59 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <4A558500-BEFE-4613-9E6F-DA4423769E93@steffann.nl> References: <20110923140052.GA41839@cilantro.c4inet.net> <4A558500-BEFE-4613-9E6F-DA4423769E93@steffann.nl> Message-ID: <23219DFF-590D-4E14-8DD2-FA22EA7EAEC5@baycix.de> Hi, > Hi Sasha, > >> I thus withdraw my support for this change unless the "extensive >> documentation" requirement is removed. > > > This is not part of the policy but a suggestion to the RIPE NCC. It seemed useful information to have, but if people think it is not then we won't suggest this to the NCC. However, all of this is part of the implementation (which is up to the NCC) and not part of the policy. The policy hasn't changed. > > Considering that this well-intended suggestion to the NCC seems to have caused controversy and distract from the actual policy proposal we will not send the suggestion to the NCC. while i certainly think that this idea was well intended (it actually makes some sense to me in general, but not in this context), i am happy to hear that we can go on with this one without any more discussion. Still supporting 2011-02 :-) -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From lists-ripe at c4inet.net Fri Sep 23 16:28:36 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Fri, 23 Sep 2011 14:28:36 +0000 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <4A558500-BEFE-4613-9E6F-DA4423769E93@steffann.nl> References: <20110923140052.GA41839@cilantro.c4inet.net> <4A558500-BEFE-4613-9E6F-DA4423769E93@steffann.nl> Message-ID: <20110923142836.GB41839@cilantro.c4inet.net> Hi Sander, On Fri, Sep 23, 2011 at 04:11:35PM +0200, Sander Steffann wrote: >This is not part of the policy but a suggestion to the RIPE NCC. >It seemed useful information to have, but if people think it is >not then we won't suggest this to the NCC. However, all of this >is part of the implementation (which is up to the NCC) and not >part of the policy. The policy hasn't changed. This suggestion, if followed, would implicitly become policy without consensus from the PDP. I assume that is what Nick alludes to in his reply. IMO, that would be a dangerous precedent to set. Besides, the request form already contains the "why-pi" question. A requirement to "prove that you're worthy" would just lead to applicants concocting whatever story they think the IPRA will believe and be completely useless information. >Considering that this well-intended suggestion to the NCC seems >to have caused controversy and distract from the actual policy >proposal we will not send the suggestion to the NCC. Without the requirement I do, of course, fully support the policy. cheers, Sascha From sander at steffann.nl Fri Sep 23 16:38:04 2011 From: sander at steffann.nl (Sander Steffann) Date: Fri, 23 Sep 2011 16:38:04 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <20110923142836.GB41839@cilantro.c4inet.net> References: <20110923140052.GA41839@cilantro.c4inet.net> <4A558500-BEFE-4613-9E6F-DA4423769E93@steffann.nl> <20110923142836.GB41839@cilantro.c4inet.net> Message-ID: Hi Sasha, > Besides, the request form already contains the "why-pi" question. So my suggestion was redundant anyway... > A requirement to "prove that you're worthy" would just lead to applicants concocting whatever story they think the IPRA will believe and be completely useless information. I think you misunderstood me. I wanted a (maybe bit more extensive) why-pi question. The question would be for documentation purposes only. I don't *ever* want the NCC to add a question that actually influences the decision without that being approved through the full PDP! My apologies if I created that impression. >> Considering that this well-intended suggestion to the NCC seems to have caused controversy and distract from the actual policy proposal we will not send the suggestion to the NCC. > > Without the requirement I do, of course, fully support the policy. Thank you expressing you opinion explicitly. That makes our lives as working group chairs so much easier! Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From millnert at gmail.com Fri Sep 23 17:05:14 2011 From: millnert at gmail.com (Martin Millnert) Date: Fri, 23 Sep 2011 17:05:14 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> References: <4E7C8696.2030102@inex.ie> <4E7C8A26.30104@inex.ie> <7889B02D-0A81-45E6-9454-A74C871A4069@steffann.nl> <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> Message-ID: On Fri, Sep 23, 2011 at 4:12 PM, Sander Steffann wrote: >> Let's go ahead with 2011-02 as originally stated in the policy proposal - >> without the extra interpretation. > > > Agreed, > Sander Great, thanks for resolving this. Regards, Martin (... and I approve of this message) From emadaio at ripe.net Mon Sep 26 14:05:56 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 26 Sep 2011 14:05:56 +0200 Subject: [address-policy-wg] 2011-02 Last Call for Comments (Removal of multihomed requirement for IPv6 PI) Message-ID: Dear Colleagues, The proposal described in 2011-02, "Removal of multihomed requirement for IPv6 PI", is now at its Concluding Phase. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-02 Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 24 October 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC From stolpe at resilans.se Mon Sep 26 15:46:19 2011 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 26 Sep 2011 15:46:19 +0200 (CEST) Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C8696.2030102@inex.ie> <4E7C8A26.30104@inex.ie> <7889B02D-0A81-45E6-9454-A74C871A4069@steffann.nl> <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> Message-ID: On Fri, 23 Sep 2011, Martin Millnert wrote: > On Fri, Sep 23, 2011 at 4:12 PM, Sander Steffann wrote: >>> Let's go ahead with 2011-02 as originally stated in the policy proposal - >>> without the extra interpretation. >> >> >> Agreed, >> Sander > > Great, thanks for resolving this. > > Regards, > Martin (... and I approve of this message) Indeed. Do we see som light in the tunnel eventually? ;-) Best Regards, 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 From sm+afrinic at elandsys.com Tue Sep 27 11:09:15 2011 From: sm+afrinic at elandsys.com (S Moonesamy) Date: Tue, 27 Sep 2011 02:09:15 -0700 Subject: [address-policy-wg] 2011-01 Last Call for Comments (Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA) In-Reply-To: <201109060916.p869GdRI030035@esl.local> References: <201109060916.p869GdRI030035@esl.local> Message-ID: <6.2.5.6.2.20110927020428.0a4f6d78@resistor.net> At 02:16 06-09-2011, Emilio Madaio wrote: >The proposal described in 2011-01, "Global Policy for post exhaustion >IPv4 allocation mechanisms by the IANA", is now at its Concluding >Phase. FYI, the ARIN CEO posted a message ( http://lists.arin.net/pipermail/arin-ppml/2011-September/023220.html ) about the IANA review. Regards, S. Moonesamy From gert at space.net Wed Sep 28 10:04:17 2011 From: gert at space.net (Gert Doering) Date: Wed, 28 Sep 2011 10:04:17 +0200 Subject: [address-policy-wg] (Draft) minutes from APWG Meeting at RIPE 62 Message-ID: <20110928080417.GC72014@Space.Net> Hello Working Group, the draft minutes from the APWG sessions at the last RIPE meeting have now been published: http://www.ripe.net/ripe/groups/wg/ap/minutes/minutes-from-ripe-62 please let us know if there is anything that needs to be corrected or amended. Thanks to the RIPE NCC for their work on this, and apologies to the WG for the delay in publishing - that was all my doing, dragging my feet with the initial review. 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 (89) 32356-444 USt-IdNr.: DE813185279 From dr at cluenet.de Wed Sep 28 15:55:35 2011 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 28 Sep 2011 15:55:35 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> References: <4E7C8696.2030102@inex.ie> <4E7C8A26.30104@inex.ie> <7889B02D-0A81-45E6-9454-A74C871A4069@steffann.nl> <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> Message-ID: <20110928135535.GA24136@srv03.cluenet.de> On Fri, Sep 23, 2011 at 04:12:46PM +0200, Sander Steffann wrote: > > Let's go ahead with 2011-02 as originally stated in the policy proposal - > > without the extra interpretation. > > Agreed, > Sander Under that provision, I do fully support the proposal 2011-02. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From turchanyi.geza at gmail.com Wed Sep 28 16:45:39 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Wed, 28 Sep 2011 16:45:39 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <20110928135535.GA24136@srv03.cluenet.de> References: <4E7C8696.2030102@inex.ie> <4E7C8A26.30104@inex.ie> <7889B02D-0A81-45E6-9454-A74C871A4069@steffann.nl> <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> Message-ID: Hi, I can not support this policy unless explicit restrictions added. 1, If the number of IPv6 PI slots allocated reaches a certain level then the policy should be immediatly reviewed; The number of the IPv6 PI slots allocated must not exceed the numbers of the LIRs in the regions; however, a lower limit would be also fine for me. 2, The policy should include the warning that ISPs might filter off the announcements of small sized slots from their routing table. Thanks, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Wed Sep 28 17:13:59 2011 From: nick at inex.ie (Nick Hilliard) Date: Wed, 28 Sep 2011 16:13:59 +0100 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C8696.2030102@inex.ie> <4E7C8A26.30104@inex.ie> <7889B02D-0A81-45E6-9454-A74C871A4069@steffann.nl> <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> Message-ID: <4E8339B7.7050409@inex.ie> On 28/09/2011 15:45, Turchanyi Geza wrote: > 1, If the number of IPv6 PI slots allocated reaches a certain level then > the policy should be immediatly reviewed; The number of the IPv6 PI slots > allocated must not exceed the numbers of the LIRs in the regions; however, > a lower limit would be also fine for me. I don't think there is a requirement to force a review at a particular number of registrations. G?za, if you disagree with this, there is nothing to stop you from submitting a new policy proposal when the number of ipv6 pi registrations reaches whatever level you believe is sufficient. > 2, The policy should include the warning that ISPs might filter off the > announcements of small sized slots from their routing table. This is already in the policy: http://www.ripe.net/ripe/docs/ripe-523#routability Nick From sander at steffann.nl Wed Sep 28 19:10:43 2011 From: sander at steffann.nl (Sander Steffann) Date: Wed, 28 Sep 2011 19:10:43 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C8696.2030102@inex.ie> <4E7C8A26.30104@inex.ie> <7889B02D-0A81-45E6-9454-A74C871A4069@steffann.nl> <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> Message-ID: Hi G?za, > 1, If the number of IPv6 PI slots allocated reaches a certain level then the policy should be immediatly reviewed; The number of the IPv6 PI slots allocated must not exceed the numbers of the LIRs in the regions; however, a lower limit would be also fine for me. That is not how the policy development process works. Anybody can submit a policy proposal at any time. We don't define specific points in time or arbitrary numbers at which we do policy reviews or changes. On the other hand: such a change is not needed. You can initiate such a review yourself at any time you want. This mailing list is always available for discussing/reviewing policies. We will make sure that we will have reports from the RIPE NCC to use as the basis for this. The line about routability applies to all address space, not only PI space. A warning about this is already included in the existing policy text. Thanks, Sander Steffann -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From maildanrl at googlemail.com Wed Sep 28 23:49:19 2011 From: maildanrl at googlemail.com (Dan Luedtke) Date: Wed, 28 Sep 2011 23:49:19 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: Message-ID: Hello working group, On Fri, Sep 23, 2011 at 2:15 PM, Sander Steffann wrote: > The intention of this is to be able to analyze the reasons for organizations to request PI space and to make requesters think twice when requesting PI space. I support the policy change, even if (out of the blue for me) there is a additional burden of explaining my request for documentation. As I understood, explanations for PIv6 requests are to be documented by RIPE, but those explanations won't be a reason to reject requests if all other requirements are meet. I'd like to encourage everyone to make clear that this is optional. Nevertheless, this is not what was actually proposed, is it? regards, Dan -- danrl / Dan Luedtke http://www.danrl.de From pk at DENIC.DE Wed Sep 28 22:57:24 2011 From: pk at DENIC.DE (Peter Koch) Date: Wed, 28 Sep 2011 22:57:24 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C8696.2030102@inex.ie> <4E7C8A26.30104@inex.ie> <7889B02D-0A81-45E6-9454-A74C871A4069@steffann.nl> <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> Message-ID: <20110928205724.GV3290@x27.adm.denic.de> Sander, > That is not how the policy development process works. Anybody can submit a policy proposal at any time. i do not believe this reflects the full wisdom and history of the PDP. There is a difference between opening the flood gates and then starting another proposal to get them closed and opening the flood gates and determining in advance that they be closed once the dam reservoir is half full (or ~ empty). Both are possible under the PDP and i'd suggest that 2009-03 might well serve as a precedent for such a "dynamic" policy. -Peter (not taking any position w.r.t. the policy proposal or Geza's remark) From swmike at swm.pp.se Thu Sep 29 07:36:36 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 29 Sep 2011 07:36:36 +0200 (CEST) Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <20110928205724.GV3290@x27.adm.denic.de> References: <4E7C8696.2030102@inex.ie> <4E7C8A26.30104@inex.ie> <7889B02D-0A81-45E6-9454-A74C871A4069@steffann.nl> <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> Message-ID: On Wed, 28 Sep 2011, Peter Koch wrote: > i do not believe this reflects the full wisdom and history of the PDP. > There is a difference between opening the flood gates and then starting > another proposal to get them closed and opening the flood gates and > determining in advance that they be closed once the dam reservoir is > half full (or ~ empty). Both are possible under the PDP and i'd suggest > that 2009-03 might well serve as a precedent for such a "dynamic" > policy. I fear DFZ bloat. I have a hard time imagining that the policy group would change the PI policy even if there were an PI rate explosion, because of vested interest in keeping the policy in place from a large volume of people. I would feel a lot more ease at mind if there were some kind of provision in it that would actually put a cap on number of PI blocks and force an mandatory re-consideration (or review or what not) of the policy (even though this might pass anyhow because of the beforementioned vested interests). This can be put quite high, let's say 100k in 10 years for the RIPE region (I haven't put too much thought into the actual number). This would curb my doubts about it and I would fully support it, and the people saying there won't be a PI rate explosion shouldn't have much problem with it either, because if they're right, this provision would never come into effect. I also have no problem passing the current policy so we can change IPv6 PI rules, and discuss the actual cap number during the next coming months. -- Mikael Abrahamsson email: swmike at swm.pp.se From sander at steffann.nl Thu Sep 29 09:34:56 2011 From: sander at steffann.nl (Sander Steffann) Date: Thu, 29 Sep 2011 09:34:56 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: Message-ID: Hi Dan, > On Fri, Sep 23, 2011 at 2:15 PM, Sander Steffann wrote: >> The intention of this is to be able to analyze the reasons for organizations to request PI space and to make requesters think twice when requesting PI space. > > I support the policy change, even if (out of the blue for me) there is > a additional burden of explaining my request for documentation. As I > understood, explanations for PIv6 requests are to be documented by > RIPE, but those explanations won't be a reason to reject requests if > all other requirements are meet. That is what I suggested, but... > I'd like to encourage everyone to > make clear that this is optional. > > Nevertheless, this is not what was actually proposed, is it? ... my suggestion caused confusion and comments, so I'm not suggesting it anymore :-) What is proposed is exactly what is described in http://www.ripe.net/ripe/policies/proposals/2011-02. The only thing we ask the NCC is to regularly report / provide statistics on the effects of this policy. Thanks, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From sander at steffann.nl Thu Sep 29 09:44:15 2011 From: sander at steffann.nl (Sander Steffann) Date: Thu, 29 Sep 2011 09:44:15 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C8696.2030102@inex.ie> <4E7C8A26.30104@inex.ie> <7889B02D-0A81-45E6-9454-A74C871A4069@steffann.nl> <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> Message-ID: Hi Mikael, > I fear DFZ bloat. I have a hard time imagining that the policy group would change the PI policy even if there were an PI rate explosion, because of vested interest in keeping the policy in place from a large volume of people. > > I would feel a lot more ease at mind if there were some kind of provision in it that would actually put a cap on number of PI blocks and force an mandatory re-consideration (or review or what not) of the policy (even though this might pass anyhow because of the beforementioned vested interests). This can be put quite high, let's say 100k in 10 years for the RIPE region (I haven't put too much thought into the actual number). > > This would curb my doubts about it and I would fully support it, and the people saying there won't be a PI rate explosion shouldn't have much problem with it either, because if they're right, this provision would never come into effect. I have serious doubts about setting an arbitrary cap and thereby creating 'fake' scarcity of a resource. It can also backfire: 'we see that things are going the wrong way, but we haven't reached the cap yet, so we'll wait until that happens'. The current PDP allows anyone to propose a policy change at any time, as soon as they see that something is wrong. I feel much more comfortable with that. But I am just a co-chair here. Decisions are made by the working group (everybody on this mailing list), not by me :-) If there is consensus that putting in a cap would be a good idea then that is what happens, and I'll give it my full support. > I also have no problem passing the current policy so we can change IPv6 PI rules, and discuss the actual cap number during the next coming months. That would be great. Thanks, Sander Steffann -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From turchanyi.geza at gmail.com Thu Sep 29 18:22:21 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Thu, 29 Sep 2011 18:22:21 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C8696.2030102@inex.ie> <4E7C8A26.30104@inex.ie> <7889B02D-0A81-45E6-9454-A74C871A4069@steffann.nl> <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> Message-ID: Hi, Thanks, Peter for your comments. Some people assumes that any change will be slow and we will have time to react. Perhaps we will have two years, as the policy development takes about two years. I do not think that this approach is safe enough. If the number of PI address space chunks exceed the number of LIRs than we might realise that the RIPE NCC works mostly for the PI address owners. Is this our intention? If RIPE would allow 100 000 PI route objects to be created and other RIR would do the same than the Internet would die very soon. OR: All ISP would filter of all PI annuoncements ;-) and all PI address would became totally useless. More route object not only mean more memories and perhaps new linecards/routers, however, also slow down of routing convergence. So, please be realistic, and formulate some realistic limits NOW. The numebr of LIRs served is just a hint, however, not a bad hint. Best, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Thu Sep 29 18:52:33 2011 From: sander at steffann.nl (Sander Steffann) Date: Thu, 29 Sep 2011 18:52:33 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C8696.2030102@inex.ie> <4E7C8A26.30104@inex.ie> <7889B02D-0A81-45E6-9454-A74C871A4069@steffann.nl> <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> Message-ID: Hi Geza, I must admit that policy development has been very slow in some cases, but we also have had cases where the PDP was completed in months. But I see your point. But setting an arbitrary limit still feels wrong to me. How about taking this a bit further and reviewing policies regularly, like for example at every RIPE meeting? And we could review more than just the IPv6 PI policy... It will cause extra work for us as chairs, but it might be useful to do. - Sander From turchanyi.geza at gmail.com Thu Sep 29 20:18:15 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Thu, 29 Sep 2011 20:18:15 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C8696.2030102@inex.ie> <4E7C8A26.30104@inex.ie> <7889B02D-0A81-45E6-9454-A74C871A4069@steffann.nl> <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> Message-ID: Hello Sander, many thanks for your proposal. On Thu, Sep 29, 2011 at 6:52 PM, Sander Steffann wrote: > Hi Geza, > > I must admit that policy development has been very slow in some cases, but > we also have had cases where the PDP was completed in months. But I see your > point. > Thanks. > > But setting an arbitrary limit still feels wrong to me. How about taking > this a bit further and reviewing policies regularly, like for example at > every RIPE meeting? And we could review more than just the IPv6 PI policy... > > It will cause extra work for us as chairs, but it might be useful to do. > > - Sander > I still think it is better to set a limit with an educated guess and review it on the RIPE meeting... This would allow us fexibility while the process can not become uncontrolled. There will be no unforeseen side effects.... Thanks again, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Thu Sep 29 20:42:59 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 29 Sep 2011 11:42:59 -0700 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C8696.2030102@inex.ie> <4E7C8A26.30104@inex.ie> <7889B02D-0A81-45E6-9454-A74C871A4069@steffann.nl> <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> Message-ID: It's worth noting that a similar PI policy has been in place in the ARIN region for some time now, and has not resulted in any large increase in the IPv6 routing table. Just my .18 euros, Scott On Thu, Sep 29, 2011 at 9:22 AM, Turchanyi Geza wrote: > Hi, > > Thanks, Peter for your comments. > > Some people assumes that any change will be slow and we will have time to > react. Perhaps we will have two years, as the policy development takes about > two years. > > I do not think that this approach is safe enough. > > If the number of PI address space chunks exceed the number of LIRs than we > might realise that the RIPE NCC works mostly for the PI address owners. Is > this our intention? > > If RIPE would allow 100 000 PI route objects to be created and other RIR > would do the same than the Internet would die very soon. OR: All ISP would > filter of all PI annuoncements ;-) and all PI address would became totally > useless. > > More route object not only mean more memories and perhaps new > linecards/routers, however, also slow down of routing convergence. > > So, please be realistic, and formulate some realistic limits NOW. > > The numebr of LIRs served is just a hint, however, not a bad hint. > > Best, > > G?za > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Thu Sep 29 20:56:45 2011 From: gert at space.net (Gert Doering) Date: Thu, 29 Sep 2011 20:56:45 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> Message-ID: <20110929185645.GY72014@Space.Net> Hi, On Thu, Sep 29, 2011 at 11:42:59AM -0700, Scott Leibrand wrote: > It's worth noting that a similar PI policy has been in place in the ARIN > region for some time now, and has not resulted in any large increase in the > IPv6 routing table. Yes. I have watched the global table fairly closely for the last years, and indeed, the number of PI routes in the global IPv6 table is well under control so far (and the rate it's growing is also under control). Slides up to May are in my RIPE62 IPv6 routing table report, but if it helps, I can go through the numbers and provide up-to-date graphs. Sander's announcement also had the most recent numbers of PA-vs-PI routes in it. Gert Doering -- just providing background data -- 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 (89) 32356-444 USt-IdNr.: DE813185279 From swmike at swm.pp.se Thu Sep 29 21:14:25 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 29 Sep 2011 21:14:25 +0200 (CEST) Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <20110929185645.GY72014@Space.Net> References: <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> Message-ID: On Thu, 29 Sep 2011, Gert Doering wrote: > Sander's announcement also had the most recent numbers of PA-vs-PI > routes in it. My worry horizon isn't the next 3years, it's the next 10-50 years. We need to enable renumbering and multihoming without DFZ slot for end entity, and easing PI requirements just makes the chance of this actually being implemented that much less likely. -- Mikael Abrahamsson email: swmike at swm.pp.se From turchanyi.geza at gmail.com Thu Sep 29 21:49:16 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Thu, 29 Sep 2011 21:49:16 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <20110929185645.GY72014@Space.Net> References: <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> Message-ID: Gert and all, On Thu, Sep 29, 2011 at 8:56 PM, Gert Doering wrote: > Hi, > > On Thu, Sep 29, 2011 at 11:42:59AM -0700, Scott Leibrand wrote: > > It's worth noting that a similar PI policy has been in place in the ARIN > > region for some time now, and has not resulted in any large increase in > the > > IPv6 routing table. > > Yes. I have watched the global table fairly closely for the last years, > and indeed, the number of PI routes in the global IPv6 table is well > under control so far (and the rate it's growing is also under control). > > Slides up to May are in my RIPE62 IPv6 routing table report, but if it > helps, I can go through the numbers and provide up-to-date graphs. > > Sander's announcement also had the most recent numbers of PA-vs-PI routes > in it. > Right. If the situation remain reasonable, then the educatedly guessed limit will never hit, and everybody will be happy. However, I think we should be prepared for the worst scenario as well. > > Gert Doering > -- just providing background data > Best, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel at arneill-py.sacramento.ca.us Fri Sep 30 07:13:04 2011 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 29 Sep 2011 22:13:04 -0700 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C929D.2020901@inex.ie><47C99329-19C2-428C-B692-30FA063A6339@steffann.nl><20110928135535.GA24136@srv03.cluenet.de><20110928205724.GV3290@x27.adm.denic.de><20110929185645.GY72014@Space.Net> Message-ID: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> > Mikael Abrahamsson wrote: > My worry horizon isn't the next 3 years, it's the next > 10-50 years. We need to enable renumbering and multihoming > without DFZ slot for end entity, and easing PI requirements > just makes the chance of this actually being implemented > that much less likely. Sounds good, but you have it all backwards. The very reason we have IPv6 PI now is because easy renumbering and non-PI multihoming are red herrings. For the last 15 years, the IETF has lived on a lie that these features will be delivered. They have not. I hate to sound brutal, but why should I believe that you will find the Holy Grail that everyone else has been searching for over the last 15 years? I heard it all, I wrote part of it. There is NO solution to make renumbering easy and there is NO solution nearly as good as PI for multihoming. Stop the vaporware. What you want does not exist. Unlike the IETF, ARIN has recognized that fact, and this is why we have IPv6 PI; it does not fulfill the initial IPv6 dream of a strongly aggregated, PA-only routing table but it's the best we have today. I'm tired of hearing "we need to". I have been hearing this for 15 years, enough of this. Oh, BTW, I tried too. You don't have anything; when you do, deliver it and come back to us. Michel. From bmanning at vacation.karoshi.com Fri Sep 30 07:17:13 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 30 Sep 2011 05:17:13 +0000 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> References: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> Message-ID: <20110930051713.GA11849@vacation.karoshi.com.> On Thu, Sep 29, 2011 at 10:13:04PM -0700, Michel Py wrote: > > Mikael Abrahamsson wrote: > > My worry horizon isn't the next 3 years, it's the next > > 10-50 years. We need to enable renumbering and multihoming > > without DFZ slot for end entity, and easing PI requirements > > just makes the chance of this actually being implemented > > that much less likely. > > I hate to sound brutal, but why should I believe that you will find the > Holy Grail that everyone else has been searching for over the last 15 > years? I heard it all, I wrote part of it. There is NO solution to make > renumbering easy and there is NO solution nearly as good as PI for > multihoming. > > Michel. DFZ slots are for those who pay for them... /bill From swmike at swm.pp.se Fri Sep 30 07:36:05 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 30 Sep 2011 07:36:05 +0200 (CEST) Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> References: <4E7C929D.2020901@inex.ie><47C99329-19C2-428C-B692-30FA063A6339@steffann.nl><20110928135535.GA24136@srv03.cluenet.de><20110928205724.GV3290@x27.adm.denic.de><20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> Message-ID: On Thu, 29 Sep 2011, Michel Py wrote: > I hate to sound brutal, but why should I believe that you will find the > Holy Grail that everyone else has been searching for over the last 15 > years? I heard it all, I wrote part of it. There is NO solution to make > renumbering easy and there is NO solution nearly as good as PI for > multihoming. I am well aware of this. > Stop the vaporware. What you want does not exist. Unlike the IETF, ARIN I never said it did. > I'm tired of hearing "we need to". I have been hearing this for 15 > years, enough of this. Oh, BTW, I tried too. You don't have anything; > when you do, deliver it and come back to us. We still need to in the long term. IPv6 PI, ie keeping state for all end-users in all DFZ routers on the Internet, does not scale with billions of routes. So yes, there is no solution right now, that doesn't mean IPv6 PI is any kind of long term solution. We know it's bad, we still use it because there is no better way right now. That doesn't mean we should give up. It's again tragedy of the commons. For the individual user, PI is always the easiest way out. For humanity/Internet as a whole in the long term, not so much. But let's get IPv6 implemented, a few hundred thousand more routes doesn't really matter, as long as they don't turn into many millions. -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Fri Sep 30 08:26:32 2011 From: randy at psg.com (Randy Bush) Date: Fri, 30 Sep 2011 15:26:32 +0900 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <20110930051713.GA11849@vacation.karoshi.com.> References: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> Message-ID: > DFZ slots are for those who pay for them... until i see where the actual monetary trading market is for so-called dfz slots, i call this bs randy From slz at baycix.de Fri Sep 30 09:07:45 2011 From: slz at baycix.de (Sascha Lenz) Date: Fri, 30 Sep 2011 09:07:45 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C929D.2020901@inex.ie><47C99329-19C2-428C-B692-30FA063A6339@steffann.nl><20110928135535.GA24136@srv03.cluenet.de><20110928205724.GV3290@x27.adm.denic.de><20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> Message-ID: <93AB2083-7952-4028-8C07-79D5A8732C05@baycix.de> Hi, [...] > We still need to in the long term. IPv6 PI, ie keeping state for all end-users in all DFZ routers on the Internet, does not scale with billions of routes. > While this might be true indeed - in the long term - it also might be possible that - in the long term - it does scale by some magic trick of some very intelligent maths person and some cool vendor. So we're only guessing here. At the moment you're certainly right. > So yes, there is no solution right now, that doesn't mean IPv6 PI is any kind of long term solution. We know it's bad, we still use it because there is no better way right now. That doesn't mean we should give up. > > It's again tragedy of the commons. For the individual user, PI is always the easiest way out. For humanity/Internet as a whole in the long term, not so much. > > But let's get IPv6 implemented, a few hundred thousand more routes doesn't really matter, as long as they don't turn into many millions. I think the problem is not (yet) the total amount of prefixes, but the rate of growth. As long as the tables don't grow too fast, i think there is not so much of a problem since the vendors can keep up with this and companies can plan for upgrades. If the tables grow too fast, this will be indeed a bigger problem, but there are no signs yet that this will happen (in the IPv6 tables at least, not so sure about IPv4 tables post depletion with all the expected fragmentations :-/ ). But again, just my 0.02EUR on this, also only educated guesses here based on the numbers we have seen. Bottom line: It's nothing we need to discuss or make into policy at this very moment. We just need to keep an eye on it, and i'm sure we will. I'm very certain that the majority of the community will agree to another policy as soon as the majority does have a problem with the size of the tables. For the moment, i just see the majority having problems with the current asymmetric IPv4 + IPv6 PI policies, and that's what this policy draft is about, nothing else. I'm a bit disappointed that this one is hijacked and used for general PI policy discussions over and over. I really would suggest writing another, general (IPv4+IPv6) policy draft for this and discuss these long-term issues there. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From turchanyi.geza at gmail.com Fri Sep 30 09:50:00 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Fri, 30 Sep 2011 09:50:00 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> Message-ID: Hi Mike, On Fri, Sep 30, 2011 at 7:36 AM, Mikael Abrahamsson wrote: > On Thu, 29 Sep 2011, Michel Py wrote: > > I hate to sound brutal, but why should I believe that you will find the >> Holy Grail that everyone else has been searching for over the last 15 years? >> I heard it all, I wrote part of it. There is NO solution to make renumbering >> easy and there is NO solution nearly as good as PI for multihoming. >> > > I am well aware of this. > > > Stop the vaporware. What you want does not exist. Unlike the IETF, ARIN >> > > I never said it did. > > > I'm tired of hearing "we need to". I have been hearing this for 15 years, >> enough of this. Oh, BTW, I tried too. You don't have anything; when you do, >> deliver it and come back to us. >> > > We still need to in the long term. IPv6 PI, ie keeping state for all > end-users in all DFZ routers on the Internet, does not scale with billions > of routes. > > So yes, there is no solution right now, that doesn't mean IPv6 PI is any > kind of long term solution. Yes, fully agree here. > We know it's bad, we still use it because there is no better way right now. > That doesn't mean we should give up. > > It's again tragedy of the commons. For the individual user, PI is always > the easiest way out. For humanity/Internet as a whole in the long term, not > so much. > > But let's get IPv6 implemented, a few hundred thousand more routes doesn't > really matter, as long as they don't turn into many millions. > > I realy would like to know what makes you so optimistic? While you think so that a few hundred thousands more routes doesn!t really matter? Which kind of routers/line cards could support this at wire speed? Any summary of convergence issues in large scale network? Am I missed some new technology that is already implemented allmost everywhere? > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > I would be glad to receive additional information here, if this exists, please share it! Many thanks, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Fri Sep 30 10:09:51 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 30 Sep 2011 10:09:51 +0200 (CEST) Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> Message-ID: On Fri, 30 Sep 2011, Turchanyi Geza wrote: > I realy would like to know what makes you so optimistic? While you think > so that a few hundred thousands more routes doesn!t really matter? > > Which kind of routers/line cards could support this at wire speed? Any > summary of convergence issues in large scale network? As far as I know, Cisco 7600 with XL PFC, Juniper MX, Cisco ASR 9k, CRS etc, all handle 1M or more routes, or at least a mix of 0.5M IPv4 and 0.25k IPv6 routes. I don't see why number of IPv6 routes would converge a lot slower than number of IPv4 routes. > Am I missed some new technology that is already implemented allmost > everywhere? Prefix independent convergence, ie BGP prefix points to loopback which points to outgoing interface. When you need to converge your IGP you just rewrite the loopback pointers. This doesn't help EBGP of course, but number of routes are increasing slower tham moores law, so as long as the router vendors implement RIB processing in modern hw (not PPC :P), RIB handling is fine. Still, a lot of platforms can only program approximately 10k prefixes per second into hw, so increasing number of prefixes by hundreds of thousands means tens of seconds of increased convergence times for EBGP. -- Mikael Abrahamsson email: swmike at swm.pp.se From turchanyi.geza at gmail.com Fri Sep 30 10:28:54 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Fri, 30 Sep 2011 10:28:54 +0200 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> Message-ID: Hello Mike, OK, then we see both the same, just the interpretation is different. Lets see the details. On Fri, Sep 30, 2011 at 10:09 AM, Mikael Abrahamsson wrote: > On Fri, 30 Sep 2011, Turchanyi Geza wrote: > > I realy would like to know what makes you so optimistic? While you think >> so that a few hundred thousands more routes doesn!t really matter? >> >> Which kind of routers/line cards could support this at wire speed? Any >> summary of convergence issues in large scale network? >> > > As far as I know, Cisco 7600 with XL PFC, Juniper MX, Cisco ASR 9k, CRS > etc, all handle 1M or more routes, or at least a mix of 0.5M IPv4 and 0.25k > IPv6 routes. I don't see why number of IPv6 routes would converge a lot > slower than number of IPv4 routes. > > Am I missed some new technology that is already implemented allmost >> everywhere? >> > So the hardwired limit of 0.5M IPv4 routes and 0.25k IPv6 does not allow a few hundred thousands more IPv6 routes at all (not even would allow an 0.25M IPv6 limit) -- and speed of processing is an other issue... > > Prefix independent convergence, ie BGP prefix points to loopback which > points to outgoing interface. When you need to converge your IGP you just > rewrite the loopback pointers. > > This doesn't help EBGP of course, but number of routes are increasing > slower tham moores law, so as long as the router vendors implement RIB > processing in modern hw (not PPC :P), RIB handling is fine. > > Still, a lot of platforms can only program approximately 10k prefixes per > second into hw, so increasing number of prefixes by hundreds of thousands > means tens of seconds of increased convergence times for EBGP. > Agreed. Convergence is an issue!!! > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > In summary: we do not have the technology which would allow a very liberal PI allocation policy, therefore a very liberal PI allocation policy is not possible now. Strict limits must be kept. Thanks, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Fri Sep 30 10:33:23 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 30 Sep 2011 10:33:23 +0200 (CEST) Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> Message-ID: On Fri, 30 Sep 2011, Turchanyi Geza wrote: > So the hardwired limit of 0.5M IPv4 routes and 0.25k IPv6 does not allow > a few hundred thousands more IPv6 routes at all (not even would allow an > 0.25M IPv6 limit) -- and speed of processing is an other issue... Huh? Hardwired? It's not fixed, it is either configurable or dynamic, depending on platform. > In summary: we do not have the technology which would allow a very liberal > PI allocation policy, therefore a very liberal PI allocation policy is not > possible now. Yes. Current level of proposed "strictness" is ok for me right now, but I definitely believe it needs to be monitored closely. -- Mikael Abrahamsson email: swmike at swm.pp.se From bmanning at vacation.karoshi.com Fri Sep 30 14:20:28 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 30 Sep 2011 12:20:28 +0000 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> Message-ID: <20110930122028.GA11973@vacation.karoshi.com.> On Fri, Sep 30, 2011 at 03:26:32PM +0900, Randy Bush wrote: > > DFZ slots are for those who pay for them... > > until i see where the actual monetary trading market is for so-called > dfz slots, i call this bs > > randy at the mo, this is not a specific line item on the bill but I (and I suspect this is true for many of us) pay someone to carry my traffic. implicit in that payment is the use of routing table slots. so it may be BS to you, but not to me, my account manager, or my bank. as usual, YMMV /bill From nick at inex.ie Fri Sep 30 16:26:11 2011 From: nick at inex.ie (Nick Hilliard) Date: Fri, 30 Sep 2011 15:26:11 +0100 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> Message-ID: <4E85D183.2080902@inex.ie> On 30/09/2011 09:28, Turchanyi Geza wrote: > In summary: we do not have the technology which would allow a very liberal > PI allocation policy, therefore a very liberal PI allocation policy is not > possible now. > > Strict limits must be kept. I get the impression that people are talking about something which lies somewhere between "very liberal" and "strict limits". Nick From randy at psg.com Fri Sep 30 16:42:49 2011 From: randy at psg.com (Randy Bush) Date: Fri, 30 Sep 2011 23:42:49 +0900 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <20110930122028.GA11973@vacation.karoshi.com.> References: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> Message-ID: >>> DFZ slots are for those who pay for them... >> until i see where the actual monetary trading market is for so-called >> dfz slots, i call this bs > at the mo, this is not a specific line item on the bill but I (and I > suspect this is true for many of us) pay someone to carry my > traffic. implicit in that payment is the use of routing table slots. and the socks their marketing folk wear, and the paint on their office walls, and the bog paper in their loo. randy From bmanning at vacation.karoshi.com Fri Sep 30 16:55:19 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 30 Sep 2011 14:55:19 +0000 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> Message-ID: <20110930145519.GB1468@vacation.karoshi.com.> On Fri, Sep 30, 2011 at 11:42:49PM +0900, Randy Bush wrote: > >>> DFZ slots are for those who pay for them... > >> until i see where the actual monetary trading market is for so-called > >> dfz slots, i call this bs > > at the mo, this is not a specific line item on the bill but I (and I > > suspect this is true for many of us) pay someone to carry my > > traffic. implicit in that payment is the use of routing table slots. > > and the socks their marketing folk wear, and the paint on their office > walls, and the bog paper in their loo. > > randy My, you certainly have / trak much more info that I care to... /bill From randy at psg.com Fri Sep 30 17:01:55 2011 From: randy at psg.com (Randy Bush) Date: Sat, 01 Oct 2011 00:01:55 +0900 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <20110930145519.GB1468@vacation.karoshi.com.> References: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> Message-ID: >> and the socks their marketing folk wear, and the paint on their office >> walls, and the bog paper in their loo. > My, you certainly have / trak much more info that I care to... don't have to. those have actual markets! randy From millnert at gmail.com Fri Sep 30 17:43:37 2011 From: millnert at gmail.com (Martin Millnert) Date: Fri, 30 Sep 2011 17:43:37 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <20110929185645.GY72014@Space.Net> References: <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> Message-ID: Hi Gert, On Thu, Sep 29, 2011 at 8:56 PM, Gert Doering wrote: > Hi, > > On Thu, Sep 29, 2011 at 11:42:59AM -0700, Scott Leibrand wrote: >> It's worth noting that a similar PI policy has been in place in the ARIN >> region for some time now, and has not resulted in any large increase in the >> IPv6 routing table. > > Yes. ?I have watched the global table fairly closely for the last years, > and indeed, the number of PI routes in the global IPv6 table is well > under control so far (and the rate it's growing is also under control). > > Slides up to May are in my RIPE62 IPv6 routing table report, but if it > helps, I can go through the numbers and provide up-to-date graphs. I was actually looking for you the other day on IRC... I saw a couple of /48's in DFZ coming not from PIv6, but allocated by LIR's (thus, announced with different origin than the /32 they came from), the other day. IIRC, your data captured these [ easier-than-PIv6 ] allocations as well. Is that right? It would be interesting to see graphs of these and over time, if possible, to try and detect and correlate changes with policy, somehow. Thanks, Regards, Martin