- lir-wg - mailman.ripe.net

Re: Policy Statement on Address Space Allocations
by Sean Doran 26 Jan '96

26 Jan '96

Dennis said: >>[192 et al] look like swamps that are ripe for the picking. Bill said: >Already underway as part of PIER Yay. I'm looking forward to the updates. I'm even more looking forward to technology that makes renumbering tractable, because that will end this entire line of discussion pretty much forever. Sean.

1 0

Re: Policy Statement on Address Space Allocations
by Hank Nussbacher 26 Jan '96

26 Jan '96

On Thu, 25 Jan 1996 16:49:48 -0800 you said: >We've got a basic conflict between "smaller" and "better", whose resolution >will require (in the absense of really good renumbering technology) >constraining our insistance on efficient address utilization by measuring >the effect this has on routing tables. We need to get some quantitative >goals assigned to this so we can measure what is "good" and "bad". I'd >(again) suggest the following: A /19 in Amsterdam makes sense as a maximum allocation. A /19 in Uganda doesn't. I think due to different geographics we need to realize that allocation policy has to be different depending on where you are. Hank

3 5

Re: Policy Statement on Address Space Allocations
by Hank Nussbacher 26 Jan '96

26 Jan '96

On Fri, 26 Jan 1996 11:17:43 +0000 (GMT) you said: >I cannot accept that we have to >beg< RIPE like a good little provider >for address space that should be allocated to us from the USA anyway. >I will be interested to see how the RIPE actually works (and not just >listening to Daniel dictate policy by e-mail) when I go to my first RIPE >meeting next week. So far it seems like a bureaucracy that is entirely >self perpetuating and self interested without consider what the people >who pay for its very existance want. sigh. Just like an unelected >government in fact. ILAN pays RIPE and I do think that RIPE listens. If you compare RIPE to Internic, I think they are way ahead in the way of user representation. Your comments are more appropriate for Internic, IMHO. I have followed RIPE's development for the past 5 years and I will honestly say that I am glad that RIPE is what it is and that we are not in the sphere of Internic. >Peter Galbavy peter(a)demon.net Hank Nussbacher

1 0

Re: Policy Statement on Address Space Allocations
by miguel.sanz＠rediris.es 26 Jan '96

26 Jan '96

On Jan 25, 14:46, Yakov Rekhter wrote: > Subject: Re: Policy Statement on Address Space Allocations ... > > It's the other way round: SPRINT should tell his customers he can't > > guarantee 100% global Internet connectivity because he disagrees with > > the current address allocation policy of the IANA/InterNIC/RIPE NCC/AP-NIC. > > Would you assume that anyone whose address allocation follow > "the current address allocation policy of the IANA/InterNIC/RIPE NCC/AP-NIC" > is guaranteed 100% global Internet connectivity ? > No one can assume anything in this fast moving world, but at least I assume the last A of 'IANA' means 'Authority' and not 'Anarchy'. If the aim is global connectivity there must be some common rules everybody should follow. If someone has problems with them he can try to convince the authority/community to change them, but in a civilized way, without trying to impose anything to the rest of the world. Miguel __________________ __ ______________________ /_/ Miguel A. Sanz __ __ Email: miguel.sanz(a)rediris.es RedIRIS/CSIC /_/ RedIRIS /_/ Tel: + 34 1 5855152 Serrano 142 __ Fax: + 34 1 5855146 E-28006 Madrid /_/ SPAIN NETWORK MANAGER ____________ Spanish Academic & Research Network ___________________________

3 2

Re: Policy Statement on Address Space Allocations
by miguel.sanz＠rediris.es 26 Jan '96

26 Jan '96

On Jan 25, 8:20, Sean Doran wrote: > Subject: Re: Policy Statement on Address Space Allocations > ... > > Note that we make /19 allocations even though one particular ISP is > > telling the world that /18 is the minimum you ought to have these days. > > Yup. And when you make the /19 allocations, you should > tell them that in 195/8, if they are announcing a /19, a > /20, a /21, a /22, a /23 or a /24, that will not work if > they want to talk to SprintLink via a non-customer path. > It's the other way round: SPRINT should tell his customers he can't guarantee 100% global Internet connectivity because he disagrees with the current address allocation policy of the IANA/InterNIC/RIPE NCC/AP-NIC. They might want to look for a different transit provider... Regards, Miguel __________________ __ ______________________ /_/ Miguel A. Sanz __ __ Email: miguel.sanz(a)rediris.es RedIRIS/CSIC /_/ RedIRIS /_/ Tel: + 34 1 5855152 Serrano 142 __ Fax: + 34 1 5855146 E-28006 Madrid /_/ SPAIN NETWORK MANAGER ____________ Spanish Academic & Research Network ___________________________

8 8

Re: Policy Statement on Address Space Allocations
by Scott Bradner 26 Jan '96

26 Jan '96

> I think the hierarchical routeing is one step *worse* than the above. > The address *defines* the route the packets take ? What about the real, > live multi-interconnect, multi-homed Internet we use ? Maybe I have > misunderstood the way IPv6 addressing works. HR sure does sound real bad, just for grins what is your plan to keep the routing table size within the constraints of the routers without it? Scott

1 0

Re: Policy Statement on Address Space Allocations
by Sean Doran 26 Jan '96

26 Jan '96

Jeff Young wrote: | say what you will about this policy, but someone (sean?) thought | long and hard about it's implications. i didn't like the abrupt | manner in which it was implemented, but it does take guts and it | is pretty elegant: Thanks, Jeff. Once again I shall repeat my apologies -- the original intent was to make sure the filters would break things on day one, rather than retroactively apply to the number of people whose route announcements had been leaked in by mistake. Despite the immediate retrospective thought that it was a cute way to avoid accusations of collusion among big providers, I did very much regret the work you folks and others had to do when this got dropped into place. OTOH, well, there had been several months' warning about the details... But still, sorry that it wasn't as smooth as it could have been if there hadn't been a flaw in the filtering that crept in in about April, long before anyone was even really thinking of allocating from 206.0.0.0/8. However, as I think everyone remembers, after a short while, in an effort to assist in getting aggregation of the then-announced bits of 206.0.0.0/8 working OK and giving people some time to get used to the filtering, I did relax the filtering on 206.0.0.0/8 to permit /19s. As you note, this was to the benefit of other peoples' customers. | the real message is if you have a 206+ address, make sure that your | provider can put it into an aggregation block for you (or go to sprint). Right, and we have been warning our customer base for some time that if they announce a 206+ address that is not aggregatable into something reasonably big (like a /18), they run the risk of losing connectivity to other providers if they ever were to impose similar filters for business or technical reasons. Meanwhile, yes, it's a slight competitive advantage. :-) (Frankly though, that was a at first side-effect of not having the ability to do the outbound filtering immediately, but it rapidly seemed like a smart thing to do to make other people think about similar filtering. An interesting thing to wonder about is how different the early days of CIDR deployment would have been if rather than aggregating at the source, people were to have set up some sort of inbound filtering at places like MAE-EAST.) | nobody said it would be boring. :-) Yup. Sean.

1 0

Re: Policy Statement on Address Space Allocations
by John Curran 26 Jan '96

26 Jan '96

Daniel, Interesting message (limit of 1024 aggregated routes per /8); I seemed to have missed this approach in past email. It still has the side effect of encouraging downstream providers to remain with their current provider, _if_ their prefix happens to be from a block of the address space which has become fragmented and is being filtering by allocation. The only real problem I see with this approach is that there is a no peer group based on allocations, and therefore no mechanism which lets folks in the same block coerce each other into good aggregation... (Imagine email saying "Please, my fellow 206'ers, let's squeeze out another 600 routes before XXXnet's filtering deadline!", "207/8 -- Love it or leave it", and my personal favorite, the eventual 192/8 T-shirt which says "192/8 - Beyond Hope and Filters" ) /John === >Sean, > >If you insist on prefix-length filtering I have proposed a soloution >for future address space allocated via the RIPE NCC several times: > > - set your inbound prefix length filter to /19. > > - The RIPE NCC will *guarantee* that we will not make more than > 1024 non-aggregateable allocations from each /8. > > - The RIPE NCC will continue to work with the providers to > maximise aggregation. Our goal is a maximum of 1024 routes > per /8 visible at major exchange points. Incidentally this > is the same goal that you seem to have. > > - Should we fall to short of the goal in your opinion, you can > start to filter on the list of allocations which is available > from our whois database (whois -h whois.ripe.net -m 19x/8). > Note that we guarantee that these will be no more than 1024. > >Now given the current performance of everyone I personally believe >that we deserve a little relief from the 1024 goal but I am willing >to discuss on the basis above. > >Can we please enter into a discussion why this is a bad idea and/or >why it is not acceptable to you personally or your employer. > >Daniel >...

1 0

Re: Policy Statement on Address Space Allocations
by Sean Doran 26 Jan '96

26 Jan '96

Paul - Thank you for your kind words. Sprint's filtering policies have led directly to a more survivable SprintLink and ICM, which is to the benefit of Sprint's Internet customers. The trade-off is the inability to reach people who have just hooked up to other parts of the Internet for the first time and who are using addresses that are in conflict with what we feel our routers can support. So far the two (yes, two) customer-originated complaints involving reachability affected by our filtering have been resolved by straightforward renumbering of the non-SprintLink entity. There have, by comparison, been several hundred rather angry messages from non-customers who hook up and find that they can't use their freshly-acquired addresses to talk to SprintLink/ICM, and who claim never to have been warned that this was a virtual certainty. Two troubles in several months are rather obviously dwarfed by the thousands of customer-originated complaints about routing problems after major exchange points or other major routing transitions happen (we have observed major peers having serious difficulties with their routing system scaling recently), not to mention the most recent serious connectivity problem which involved working very closely with our vendor on getting new technology out the door that will let us scale with increasing traffic and hopefully better deal with the scaling of the increase of globally-announced routing informaiton. Customer feedback I have gotten about our CIDR and other routing policies tends to be very positive. Indeed, a number of our customers are active participants in CIDRD, NANOG, EOF and other forums where these policies sometimes are discussed at length, and none of them seem very shy about putting forward their own points-of-view, all of which is remembered and thought about frequently. We are, after all, very keen as a corporation to develop and maintain long-lasting relationships with our customers. It is possible that a number of unhappy customers have not made themselves heard, or that a number have simply voted with their feet on this precise issue, however there certainly has not been enough of the latter to justify any sort of re-think on this particular policy. Whenever I see "Sprint sucks" in newsgroups and mailing-lists, it's almost always because of reliability problems. One of our most serious backbone reliability problems involves routing convergence times and long-term stability, and this particular routing policy in combination with BGP dampening and other tools and techniques we've developed here, goes directly to the heart of those problems. I am always interested in proposals that will help provide a more robust and stable level of connectivity and performance to our entire customer base, and if you have any ideas that would make it reasonable to withdraw our prefix-length filters and _improve_ our routing stability, I would be very glad if you could detail them. Sean.

1 0

Re: Policy Statement on Address Space Allocations
by Robert A. Rosenberg 26 Jan '96

26 Jan '96

At 11:47 1/25/96, Daniel Karrenberg wrote: >1) The initial allocation for a newly established local registry (ISP) >*always* is a /19. There will be no discussion about this. >This is fixed, cast in stone, immutable, ... you get the idea. In >particular it will not be influenced by marketing predictions, amount of >capital available or the shoe size of the lawyers visiting our offices. >(NB: The value of /19 might change at some point, but the fact that >every newly established registry gets *the same size* initial allocation >will not.) When you allocate this /19, do you do so at such a boundary that it can be converted to a shorter (/18-/17-/16-etc) prefix at a later date thus avoiding the need to assign another block or forced renumbering (ie: "We will give you a new /18 block and you have x months to return your old /19 [ie: They are given a 2nd /19 worth of numbers and they most move their old /19 into the other half of the new /18]). If done correctly, you can reclaim the over allocation of "reserved for expansion" blocks after reaching the top of the original CIDR block and then doing the 2nd pass of NEW assignments by halving the space between "phase 1" allocations (in those segments where there has been no expansion of the /19 allocation into a /18-etc).

4 3