January 1996 - lir-wg - mailman.ripe.net

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

Re: Policy Statement on Address Space Allocations
by iljitsch＠daisy.bART.nl 26 Jan '96

26 Jan '96

Hi Randy, > > Yes. And of course you don't care about a small side-effect: it will > > drive small ISP's out of business. The only way to avoid that is to do > > business with large ISP's such as Sprint. > It will force folk who need only long prefixes to get their IP allocation > from their upstream provider. But that's not possible in the case of a multi-homed network, however small. > > So in stead of picking on people smaller than you, go after the types > > that accounce 50+ routes per AS. That's the _real_ problem! > Probably not the best metric either. What if they are all /16s? That would mean they connect more than a million hosts to the Internet. There can't all that many networks that are in this position... Let's look at a few examples. For instance, AS 1890. They announce: 15 B, 12 C, 1 /15, 4 /16, 2 /19, 2 /22. Total: 36 routes. If they get rid of the individual class C's and aggregate two of the /16's (they are consecutive) that would save 13 routes, more than a third. And AS 1103, they announce: 26 B, 12 C, 1 /9, 1 /10, 1 /11, 3 /16, 1 /17, 1 /18, 1 /19, 2 /21, 2 /22, 4 /23. Total: 55. If they renumber the class C's and the /23's and announce 145.0.0.0/8 in stead of 145.0.0.0/9, 145.128.0.0/10 and 145.192.0.0/11, that would save 16 routes, more than a quarter. Then there is AS 5390: Network Next Hop Metric LocPrf Weight Path *> 193.67.112.0/23 194.72.4.137 100 2856 2855 5390 i *> 194.134.0.0/22 194.72.4.137 100 2856 2855 5390 i *> 194.134.0.0/19 194.72.4.137 100 2856 2855 5390 i *> 194.134.4.0/23 194.72.4.137 100 2856 2855 5390 i *> 194.134.6.0 194.72.4.137 100 2856 2855 5390 i Without even renumbering they can save 3 out of 5 routes. Now I hope the good people of AS 1890, AS 1103 and AS 5390 forgive me for using their AS'es as an example, I'm sure the results will be the same for the majority of AS'es. So what does this tell us? 1. The routing table can be reduced by at least 5 - 10% by taking better advantage of aggregation opportunities. 2. Another 25% can be accomplished by renumbering individual class C's and very long (>20) prefixes. Iljitsch van Beijnum bART Internet Services

1 0

Announcement for Local IR Training Course in Lisbon
by RIPE NCC Training 26 Jan '96

26 Jan '96

* * * Announcement * * * Local Internet Registries Training Course Date: Monday, 25th March, 1996 Time: 0900 - 1700 Venue: RCCN Fundacao Calculo Cientifico Nacional (FCCN) Rede da Comunidade Cientifica Nacional Av. do Brasil, 101 1799 Lisboa Codex Portugal Course Audience --------------- The target audience for this course is personnel of European Local Internet Registries that contribute to the RIPE NCC. Material Covered ---------------- The course is a one day introduction on Internet name, address and routing policy registration procedures in Europe. It also teaches how to query and use the information registered for operational purposes. This includes the following material and activities: o Overview of name, address and routing registration procedures. o Responsibilities of both RIPE NCC and Local IR's to each other. o Wider context of the Delegated Registry system and relevant issues (IPv4 address depletion, CIDR) and how this relates to IP requests. o How to use the RIPE NCC Database. o Use of AS numbers, Routing Registry concepts and an introduction to using PRIDE tools. o DNS feedback on commor errors, how to request delegations, and pointers to useful tools. We again stress that this course will *not* teach Local Registries on how to run their business as Internet Service Providers. It is clearly focussed on registration procedures and the interaction between the RIPE NCC and local IR's. A detailed outline is appended below. The course itself will include lunch and will be free. This of course does not include your travel and subsitence ;-). How to Register --------------- Please send an RSVP to <training(a)ripe.net> if you would like to attend the course. If you have previously approached us about attending this course, we ask you to confirm that you (or a colleague) will be attending. Registrations will be accepted on a first come, first served basis. If the course is oversubscribed, we will give priority to local IRs who have paid the signup fee in 1995. If it is still oversubscribed, we will accept only one person per new local registry. We will provide additional course dates in Amsterdam as necessary. If a number of local registries so request, we will present courses at other European locations. If you would like a local course or have any questions or suggestions, please do not hesitate to contact us. The RIPE NCC Training Team: Mirjam Kuehne, Daniel Karrenberg --- Course Outline -------------- For this second course, we will provide a slidebook and a reader on the day of the course, as well as electronically. Once feedback is received, it is planned to make detailed documentation available in the form of a guide much like the PRIDE guide. The program will divide the actual content into the following sections: 1. Introduction For those unfamiliar with the Delegated Internet Registry system and the RIPE NCC, this section will give a historical overview of how we have arrived at today's model of operation and why training of local IR's is a much needed activity. 2. IP Registry procedures This section will clarify the procedures between the RIPE NCC and local IR's with respect to requests for IP address space. It will take a step by step approach on how to complete documentation, the kind of information that is required, what the "handholding" procedure is, how to deal with very large requests, and very small requests, and more generally what criteria the RIPE NCC and local IR's use for their customers in the context of CIDR and IPv4 address depletion. 3. RIPE NCC Database This section will explain what the RIPE NCC Database is and how it fits into the scheme of other registry databases. It will cover how to create and update RIPE NCC Database objects and will explain how to query the database. 4. Routing Registry procedures This section will examine AS numbers, when you need them and how to request them. This will be set within the context of how AS numbers are used as part of the RIPE Routing Registry. Understanding the basic principles behind the Internet Routing Registry and how registering your policy is an important element in the global schema. This section will also include a brief introduction to the PRIDE tools and how they can be useful to you. 5. DNS procedures Where to request forward and reverse domain delegation. Which documentation should be completed. How reverse domain delegation requests are processed at the RIPE NCC (with a useful tool). We will also take a look at common errors in setting up DNS with respect to relevant RFCs and RIPE recommendations. Feedback Please! Throughout the course there will be ample chance for feedback and discussion with an emphasis for you to tell us how we can improve ;-). %%%%%%%%%%% PLEASE NOTE %%%%%%%%%%% Our handling of ALL course registrations is fully automated. To register for the course, please complete the registration form and send it to <training(a)ripe.net>. Please send only the registration form in your reply and edit out all other text. Add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). If you have any questions about the training course or your registration form, please contact us at <training(a)ripe.net>. You will receive a notification message that your request has been processed. Many thanks, and look forward to seeing you, RIPE NCC Training Team ---------------------------------------------------------------------------- %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) The course you plan to attend (date and location) # COURSE [ ] %END

1 0