[address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size)

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 at 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 at baycix.de         =
= Network Operations                                                   =
= BayCIX GmbH, Landshut                  * PGP public Key on demand *  =
========================================================================