2006-05 New Draft Document Published (PI Assignment Size)
PDP Number: 2006-05 PI Assignment Size Dear Colleagues We have published a draft document for the proposal described in 2006-05. This proposal suggests to have the minimum assignment size for PI assignments to be a /24 when routing is a major issue for a multihoming End User. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-05.html and the draft document at: http://www.ripe.net/ripe/draft-documents/2006-05-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 14 March 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer
+1 :) I fully support that proposal. I think it is also a good idea to add a field 'Global: Yes/No' in the requet. If for example the net is requested for private peering - it can be smaller than /24 safe as not attended to be globally reachable. If the net is requested for announcing in global routing table - it should be /24 even if customer really need 1 IP at all. Filiz Yilmaz wrote:
PDP Number: 2006-05 PI Assignment Size
Dear Colleagues
We have published a draft document for the proposal described in 2006-05.
This proposal suggests to have the minimum assignment size for PI assignments to be a /24 when routing is a major issue for a multihoming End User.
You can find the full proposal at:
http://www.ripe.net/ripe/policies/proposals/2006-05.html
and the draft document at:
http://www.ripe.net/ripe/draft-documents/2006-05-draft.html
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 14 March 2007.
Regards
Filiz Yilmaz RIPE NCC Policy Development Officer
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
I oppose that proposal, and for more than 1 reason... - "...when routing is a major issue for the End User" there is no definition of "major issue" and there is no indication regarding which entity has to qualify or check this statement. In effect this will open a path to a minimum /24 assignment per site, and PI instead of PA. - when the ISPs decide to NOT route some small address blocks then trying to circumvent their configuration and intent by messing around with address assignment policies is royally broken. If this is really an operational problem then it needs a resolution on the routing plane. - "...suggests to add an assignment criteria to make sure the PI space is assigned to those networks that really need it. Multihoming seems" I consider a policy proposal which uses words and phrases like "suggests to" an "seems" to be broken. - on a more general note, as long as the minimum assignemt size for customers receiving PA is raised to /24, too, this proposal is a real incentive to go for PI instead of PA. Wilfried.
Hi, On Wed, Feb 14, 2007 at 05:41:39PM +0000, Wilfried Woeber, UniVie/ACOnet wrote:
- on a more general note, as long as the minimum assignemt size for customers receiving PA is raised to /24, too, this proposal is a real incentive to go for PI instead of PA.
A "not" is missing somewhere in this sentence, but I think the intended meaning is clear :) (not commenting on the policy proposal itself) Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 98999 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
You are right, thanks for spotting it! It should have read "...receiving PA is not raised to /24, too... Wilfried. Gert Doering wrote:
Hi,
On Wed, Feb 14, 2007 at 05:41:39PM +0000, Wilfried Woeber, UniVie/ACOnet wrote:
- on a more general note, as long as the minimum assignemt size for customers receiving PA is raised to /24, too, this proposal is a real incentive to go for PI instead of PA.
A "not" is missing somewhere in this sentence, but I think the intended meaning is clear :)
(not commenting on the policy proposal itself)
Gert Doering -- APWG chair
Well I support the proposal El 14/02/2007, a las 18:41, Wilfried Woeber, UniVie/ACOnet escribió:
- "...when routing is a major issue for the End User"
there is no definition of "major issue" and there is no indication regarding which entity has to qualify or check this statement.
My understand of "major issue" is "when the end user is going to use it for routing to/from Internet"
In effect this will open a path to a minimum /24 assignment per site, and PI instead of PA.
Not a bad idea. If a end user wants multihoming, he will get it (becoming a LIR itself, getting a slice of a PA and announcing it independently,etc.: money talks and RIR listen) and probably (I think so) this is the least dangerous way to do it. It will increase the routing table size like any other but at least this will help to preserve some address space.
- when the ISPs decide to NOT route some small address blocks then trying to circumvent their configuration and intent by messing around with address assignment policies is royally broken. If this is really an operational problem then it needs a resolution on the routing plane.
I dont see it as an operational problem. I see it as a business problem. Companies want/need multihoming and will get it one way of another. We can set up things to do it in the least dangerous way or try to oppose it and see how things get worse.
- on a more general note, as long as the minimum assignemt size for customers receiving PA is raised to /24, too, this proposal is a real incentive to go for PI instead of PA.
I agree with that. I don't see a real reason to assign lower than /24 to any customer (and assigning less than /24 is a nightmare for reverse DNS). My two cents.
------------------------------------------------ Tecnocom Fernando Garcia Eurocomercial - Depto Técnico Josefa Valcárcel 26, Edificio Merrimack III Madrid 28027 Tel: +34 91 4359687 Fax: +34 91 4313240 e-mail: fgarcia@eurocomercial.es http://www.tecnocom.biz http://www.eurocomercial.es
Fernando García wrote:
I agree with that. I don't see a real reason to assign lower than /24 to any customer (and assigning less than /24 is a nightmare for reverse DNS).
There is a reason. If there is a address space not need to be routed globally, but need to be unique. For example, city-wide Internet exchange point. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Wilfried Woeber, UniVie/ACOnet wrote:
- on a more general note, as long as the minimum assignemt size for customers receiving PA is raised to /24, too, this proposal is a real incentive to go for PI instead of PA.
Who need PI for global routing - get it and use now without any problem. There is a difference between policy and the real. This proposal eliminates this difference. I think it is good. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Hi, Filiz Yilmaz schrieb:
PDP Number: 2006-05 PI Assignment Size
Dear Colleagues
We have published a draft document for the proposal described in 2006-05.
This proposal suggests to have the minimum assignment size for PI assignments to be a /24 when routing is a major issue for a multihoming End User. [...]
*** VOTE *** For the votecounter: This is a *YES* for the proposal in general. *** VOTE *** For those who want to continue the discussion: Yes, i actually have problems with the proposal, but only in theory. Wilfried makes some valid points. Routing-problems "should not" be solved by some address policy, this proposal might be a problem for PA vs. PI assignments ("why should i go for PA!?") and some of the wording is quite fishy ("routing being a major issue", "suggests to"). Unfortunately, i have to come up with my almighty killer-argument: "real life" :-/ a) Solving routing issues with Address Policy changes Not nice, but how do you change routing habbits? Not at all. Routing is no central thing but a distributed one. Noone can tell anyone else what/how/whom to route. Just look at the problems with de-bogonizing new /8 blocks, or the ongoing IPv6 filter-criteria discussion with personal feelings taking over routing/filter descisions because there is no tie-breaker who makes the global descision for a particular routing policy (yes, IPv6 might be a completely different thing here than IPv4, but i think you all get my point). ==> It's not possible to solve this particular problem in the routing domain. OTOH, Address Policy is a rather central thing, at least within a RIR region. So we actually CAN change something here. There is no other way to address this PI-Assignment-routing-issue than changing the assignment policy. The only valid question here is, "_IS_ there a problem? do we _need_ to change anything here?". But i guess we're already past this point. It is an actual problem for RIPE (people coming back many times when they realize what they have done with requesting >/24 Prefixes, then some lies, then they get what they really want - <=/24), and for the LIRs/Endusers since they have problems with a lenghtly Address requesting process. This policy would just fit real-life a little better. b) PI vs. PA I don't think that's a problem. People who KNOW about PI vs. PA and WANT PI, will always go for PI, nowerdays they just lie about the needed size. So i don't see a relevant amount of entities going for PI instead of PA now when this virtual "barrier" of routability falls. Of course, there will be SOME. c) IPv4-Address (& Aut-num?) space wasted? I don't care. There is IPv6 and 4byte ASNs. Please, waste IPv4 as much as possible so we can go for IPv6 :-) No issue there. d) Wording - "routing a major issue" Well that's perfectly clear i think. If the Assignment is advertised from an "PI-only" AS, that's a valid "major routing issue" for me for example. This just simplifies things. As we all know, people lie about that anyways if needed, so why make up a complicated list of valid reasons here? Hostmasters@RIPE are clueful enough to ask the right questions about fishy requests. - "The proposal also suggests to add an assignment criteria to make sure the PI space is assigned to those networks that really need it." Well this is only part of the proposal text, not of the policy draft. Bad idea, but i think it's safe to just ignore it :-) Again: Real-life == people lie anyways. And i don't want to make RIPE require thousands of documents and stuff for a simple IP assignment. This process should be _EASY_ for anyone (even with PI space). ==> Many problems with the proposal in theory, but all not real-life proof. The RIRs and LIRs have to keep up with the actual needs out there, as bad as that sounds for some of our ears :-/ P.S.: This mail might be a little confusing(?) since i was interrupted multiple times while composing it and i don't have the time for cleaning it up before sending now, sorry. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
participants (6)
-
Fernando García -
Filiz Yilmaz -
Gert Doering -
Max Tulyev -
Sascha Lenz -
Wilfried Woeber, UniVie/ACOnet