Re: Comments on -- Re: comments on "Revision of IPv4 policy doc"
- Date: Mon, 28 Jan 2002 14:08:22 +0100
Hi,
On Sat, Jan 26, 2002 at 04:14:18PM +0000, Carlos Friacas wrote:
> > > http://www.ripe.net/rs/ipv4policy.html
[..]
> Didnt had the time to review it from scratch, so ill pickup on Gert's
> comments! (hope he doesnt mind...)
I think it would be better to look at the original document, as this
will inevitably lead to discussion about some of my thoughts, and at
the same while possibly missing things in the draft that *I* thought "OK"
but that others might feel the need to comment on...
As I said, your mail leads to discussion, so I want to very briefly comment
on a few things (and would ask to postpone the sub-allocated discussion
and other things not directly related to the draft until *those* discussions
start on the lir-wg mailing list).
[..]
> > * removal of "routing considerations" is tricky issue. We need a BCP
> > document and a clear and explicit reference to that, to help answering
> > the "shall I request PA or PI" question before it even appears...
>
> Gert, have you already found the miracle solution to the multihoming
> problem? ;-)
No, as there is none. BGP multihoming may be the best solution, as may
be a solution with "many lines to the same ISP and a good SLA", or things
like BGPDNS that have been developed recently. This is why we need a BCP
document to show advantages and problems with the various solutions.
> Or "Find the best ISP you can!" is still at number one? :-)
For most end users that think they can benefit from BGP multihoming, this
*is* a viable alternative.
(But let's not discuss this here. It doesn't belong into the "what to
do about this draft" discussion).
> > * Sub-Allocations? We should re-start the discussion on *that*, and
> > possibly include the results into the policy document (avoiding a
> > re-write just after finishing it).
> >
> > If we decide that we want sub-allocations, it will affect all
> > sections that talk about assignment hierarchy (RIR->LIR->end user).
>
> Yep. My opinion is: i dont want sub-allocations. Im not seeing any
> advantages of having them.
> I think current philosophy is good.
The fact that *you* don't need sub-allocations means "you don't have to
use them". Other networks are structured differently, and sub-allocations
make much sense there.
As this is mainly a RIR to LIR issue, and not a one-LIR-to-other-LIR thing,
I don't see a reason why sub-allocations should harm your business (or
whatever) in any way - so "not using them" is fine with me, "opposing them
because *you* don't need em" would be narrow-minded.
From some comments that you make below, it seems that our networks are
structured quite differently, which would explain this comment.
We have a fair number of resellers - small ISPs with their own end user
customer base - that feel they have no need to become a LIR on their own
(being LIR costs money). Some will go that route sooner or later, others
have been here since 5 years and are still happy with using us as a LIR.
Especially for those a concept of sub-allocations would avoid much work.
But, as said in the beginning: let's not discuss sub-allocations here.
There will be a draft paper on sub-allocations "soon" (Nurani, Mirjam?),
with all the pros and cons in it - let's base the discussion on this,
and concentrate on the task at hand.
[..]
> > "Definitions" -> "Allocation" -> "An LIR is not allowed to sub-allocate..."
> > See above :-) - this is happening, and I think we should sort this out.
> Probably, but is this the majority of cases, or a little minority?
Many of the larger ISPs in Germany do it one way or the other. Dunno
about other countries.
For all the small LIRs that serve only (mainly) end users and no resellers,
it doesn't make sense, of course.
[..]
> > 5.1.8 Private address space
> >
> > I think we should make it clear that there is NO implicit "SHOULD"
> > here - it is OK to say "I do not WANT to use private addresses"
> > to warrant PA space.
>
> I understand current policy is what you are saying, but perhaps we could
> turn it better by talking about a "per situation evaluation".
[..]
> And dont we want people to use RFC space???
No. We want people to use what's The Right Solution for their network.
Insisting on RFC space is not, and insisting on "official" IPs is neither
(and "pushing" them to use RFC space unless they complain loudly is NOT
the current policy, and I want to make this crystal clear).
[..]
> > 5.1.12: IP address space replacement procedures
> >
> > Do I read this correct that if a user comes to me and says "hey, I have
> > this /20 PI space, and want to swap it into a /20 PA", and I can verify
> > that this space is actually used to more than 50%, I can assign the /20
> > even if it exceeds my AW by far?
>
> My opinion is that this case should always have the RIR's "blessing".
> Sorry for the term, im not catholic, but this is a catholic country... ;-)
Tricky thing, "opinion". This document should reflect on current policy
only, and we're not supposed to change policy, just to clarify the
documentation...
[..]
> > 5.2.4 "Assignments to other providers"
> >
> > I find the part about "what happens to existing assingments if such
> > an ISP becomes a LIR" a bit unclear. No suggestions on improvements,
> > though. Maybe add a part about motivation? I don't really see the
> > need to force end users to renumber just because their ISP became
> > a LIR on its own - *new* assignments is easy to understand, but what's
> > the gain for existing ones?
>
> Perhaps i dont understand the problem... isnt it rule number one, if you
> want to be an ISP, get an AS number and an allocation???
No. Many small ISPs are perfectly happy to use address space from their
upstream. If they exceed a certain size and customer base, usually
(but not always) they go the LIR route - but as I said above we have
resellers that use our PA space since 5 years and are still happy with
it. We have others that became LIR eventually.
For the global table and for the address wastage problem, *not* going
the "I'm ISP now, I need an AS number and my own address space" is the
better way.
... and this is where sub-allocations come into play, to be able to
manage this efficiently.
> Out of topic, i still have one problem with an university that some years
> ago thought about being an ISP and got an ASN and an allocation... Now
> they are on my "special cases" list, and are *always* a management
> nightmare... oh, and they are also some kind of "Dead LIR" to RIPE... :-)
> Didnt understand that part quite good yet...
See what I mean? Becoming a LIR and deciding to be AS/BGP multihomed
usually creates a whole new class of problems.
(Again: please let's discuss this in a different scope).
Gert Doering
-- NetMaster
--
Total number of prefixes smaller than registry allocations: 71770 (72395)
SpaceNet AG Mail: netmaster@localhost
Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0
80807 Muenchen Fax : +49-89-32356-299
