Re: Comments on -- Re: comments on "Revision of IPv4 policy doc"

[Carlos Friacas <]

On Mon, 28 Jan 2002, Gert Doering wrote:

> 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...


Will try that soon, i hope, so i dont fall into stating same view twice...



 
> 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).

Ok.


 
> [..]
> > >  * 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.

Off-topic: Hasnt yet somebody started "drafting" it?



> > 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).

Yep, my opinion too...


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

Im not forced to used them, but if its against current policy its easier
too say no to people who think otherwise and dont mind my network
structure...
Ok, but this is not really valid, we can also turn up with another
reasons... and its not a good practice too block thing for other people
with different structures... :-)


 
> 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.

Very, very different! Do you know where Portugal is, and what is our
size??? ;-)



> 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.

LIR costs money? perhaps, but its proven (my dead-lir case...) it works
also without paying RIPE... and doing thins on a "knee-basis"... :-(


 
> 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.

Ok.


 
> [..]
> > >    "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.

Hmmm... it would be better if we could get a broader perspective!


 
> [..]
> > > 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).

Ok, wider discussion here i think... 
So, we both know now that Inet "exponential" growth is a myth... Global
Routing Table is almost stable (and will be even more when we kick out the
/24's), so with the RIRs doing the job, addressing space will not be a
problem in the next decades... and if it turns out to be, well... we have
IPv6... so why bother?
The point is: if some "jerk", or lets instead call him a "visionary" ;-)
says he's got a different view from all, and the right solution for his
network is not using RFC space, and using public addresses massively
without real need... are we "hands-tied" ? So, he should get all the
addresses/allocations he wants???


 
> [..]
> > > 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...

Gert, if policy is fuzzy we dont know what policy we really have, right?
Replacement procedures are an extraordinary case, right?


 
> [..]
> > > 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.

I think few people can object to that...


 
> ... and this is where sub-allocations come into play, to be able to 
> manage this efficiently.

Ok.


 
> > 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.

Well, in this case they are not even multihomed... but we are trying to
correct that...


 
> (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
> 

Thanks,


./Carlos
                                               "Networking is fun!"
                                               "Truth is the biggest of Lies!"
-------------------
cfriacas@localhost, CMF8-RIPE, Wide Area Network WorkGroup  http://www.fccn.pt
F.C.C.N. - Fundacao para a Computacao Cientifica Nacional  fax: +351 218472167