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 * = ========================================================================