- routing-wg - mailman.ripe.net

1st draft agenda Routing WG
by SchmitzJo＠aol.com 04 Sep '00

04 Sep '00

Dear colleagues, please find enclosed the first draft of the agenda for the session of the routing working group at RIPE 37, Amsterdam. The session will be held Thursday, 14-September, 9:00 Routing WG session As announced previously, I would also like to point out that this time we have organized a workshop on multicast applications, which will be held Tuesday, 12-September, 10:00 workshop on multicast applications Details of this workshop are listed on the RIPE web pages. As usual comments, additions, changes to the agenda of the Routing WG welcome! --- R I P E 3 7 A M S T E R D A M Routing Working Group Session 14-September-2000 Draft Agenda A. Preliminaries (Joachim Schmitz) (5min) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 36 minutes - actions from earlier meetings B. RIPE Database Software Re-Implementation and Transition to RPSL (Andrei Robachevski, Joao Luis Silva Damas) (40min) C. RADB Update (Gerald Winters) (20min) D. Database Operations Update (Andrei Robachevski, Joao Luis Silva Damas) (10min) E. RIS, Status and Plans (Antony Antony, Henk Uijterwaal) (10min) F. Routing Registry Consistency Project (Andrei Robachevski, Joao Luis Silva Damas) (10min) G. Study of BGP Convergence (Abha Ahuja) (20min) H. Internet Routing Table Analysis Update (Philip Smith) (20min) I. RIPE-210 - Updates with contributions from the audience (Christian Panigl, Philip Smith) (20min) Y. General I/O with Other WGs Z. AOB --- Regards Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

RE: Routing comment
by Morgan Dollard 04 Sep '00

04 Sep '00

-----Original Message----- From: Mark Lastdrager [mailto:mark@pine.nl] Sent: Monday, September 04, 2000 11:48 To: Morgan Dollard Cc: 'routing-wg(a)ripe.net' Subject: RE: Routing comment At Mon, 4 Sep 2000, Morgan Dollard wrote: >>But what if the ethernet interface dies? Your BGP session dies with it. >>For that reason it is advised to assign the BGP peer address to your >>loopback device and set the peering from that address. > > >Exactly, why would you want to keep sending trafic over that WAN link when >the router's conection to the lan has failed? ;-) Routers can have more than one ethernet interface. Agreed, maybe i should have made a visio diagram to explain what i meant. I do agree that with 2 or more int interface you would have to use a loopback. In the case however (which is common practice for a lot of isps) where u have 2 paralel routers with 2 different bgp sessions over separate wan links to 2 different pops, runing HSRP between each other and single eth interface on each, the best way for the ISP to make sure that the customer site is still alive without having to use ping's is to make sure that is the eth goes down, the bgp sesion goes down, and the local pref at the POP will then send packets to the second pop's, without having to use back to back's between customer routers. Morgan Mark Lastdrager Pine Internet -- email: mark(a)lastdrager.nl :: ML1400-RIPE :: tel. +31-70-3111010 http://www.pine.nl :: RIPE RegID nl.pine :: fax. +31-70-3111011 PGP key ID 92BB81D1 :: Dutch security news @ http://security.nl Today's excuse: You've been infected by the Telescoping Hubble virus. Disclaimer ---------- This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication represents the originator's personal views and opinions, which do not necessarily reflect those of the NSC Group. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify administrator(a)nscglobal.com.

1 0

The Cidr Report
by Tony Bates 01 Sep '00

01 Sep '00

This is an auto-generated mail on Fri Sep 1 12:00:00 PDT 2000 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 01Sep00 0) General Status Table History ------------- Date Prefixes 250800 85144 260800 91672 270800 91299 280800 91282 290800 85417 300800 85709 310800 85345 010900 85543 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 6240 Number of ASes announcing only one prefix: 3082 (1039 cidr, 2043 classful) Largest number of cidr routes: 589 announced by AS705 Largest number of classful routes: 1076 announced by AS701 1) Gains by aggregating at the origin AS level --- 01Sep00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS10476 2 1 1 50.0% Sinfonet,S.A Panama AS10039 2 1 1 50.0% mire.net AS9983 1 1 0 0.0% Australian Bureau of Statistics. AS9982 1 1 0 0.0% PAICHAI UNIVERSITY AS9981 1 1 0 0.0% Iworld Networking, Inc. AS9979 1 1 0 0.0% KOREA EXCHANGE BANK AS9978 1 1 0 0.0% The University of Seoul AS9977 1 1 0 0.0% IOSYSTEM AS9974 1 1 0 0.0% KOREA SECURITIES COMPUTER CORP. B AS9973 1 1 0 0.0% KEB Futures Co. AS9968 1 1 0 0.0% Kyobo Life Insurance AS9966 1 1 0 0.0% KORAMBANK AS9962 1 1 0 0.0% Sunchon National University AS9960 1 1 0 0.0% NEW C&C CO.,LTD. AS9954 1 1 0 0.0% Kunsan National University AS9953 1 1 0 0.0% Hyundai Eng. & Const. Co., Ltd. AS9951 1 1 0 0.0% D3C Net AS9950 1 1 0 0.0% INT Co.,Ltd. AS9935 1 1 0 0.0% AGNS-Customer-KW AS9927 1 1 0 0.0% A Multihomed ISP Company AS9912 1 1 0 0.0% Quality Internet Services AS9891 1 1 0 0.0% iGreatLink.com AS9879 1 1 0 0.0% OGILVY ASIA/PACIFIC AS9877 1 1 0 0.0% Ngee Ann Polytechnic Computer Cen AS9871 1 1 0 0.0% JC Entertainment Co. AS9868 1 1 0 0.0% Catholic University of TAEGU HYOS AS9866 1 1 0 0.0% LGCAPITAL AS9862 1 1 0 0.0% YES24 CO. LTD AS9859 1 1 0 0.0% ChungCheong College AS9856 1 1 0 0.0% ec-Bank co., Ltd. For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

RE: Routing parts of another LIR's PA block
by Morgan Dollard 01 Sep '00

01 Sep '00

The major problem with Must nots and Should nots, are the underlying assumptions made by vendors. Most vendors will take a should not, and force a Must not so as to be as compliant to RFC specs as possible, and thereafter the feature will slowly become a known Must Not when in fact it is only a Should Not. This has happened before, on a number of different topics, but in the end, we are all subject to misunderstandings. I do agree though, that the practice of origininating prefixes in different AS's, needs to be established as either a should not or must not, and be applied as such. Jay, i do believe that a lack of clarification on such topics in the specs can only cause more ambiguity than anything else, and will lead to uncommon practices beign used. RFC's are documents that are used as reference, and therefor should be as clear as possible on every aspect, so as not to leave ambiguities. Thx, Morgan Dollard -----Original Message----- From: Jay Borkenhagen [mailto:jayb@braeburn.org] Sent: Friday, September 01, 2000 14:40 To: routing-wg(a)ripe.net Subject: Re: Routing parts of another LIR's PA block >> this is not bgp spec. it is rfc 1930, see appended, and is not a >> MUST NOT. Bovio> As you can see above Randy wrote that this is *NOT* a MUST NOT, Bovio> and not the opposite as people seem to believe. However, rfc1930 pre-dates rfc2119/bcp0014. Even though some authors may have used the MUST / MUST NOT / etc. notation prior to rfc2119, not all did: for example rfc1918, a prime candidate for a bunch of MUST NOTs if ever there was one, does not use such notation. Admittedly rfc1930 and rfc1918 are not documents in the standards track for which rfc2119 is most targetted, but that further implies that we can't put too much weight on a missing MUST NOT in rfc1930. I'm sure that if I'm off-base here, Randy will gently correct me. :-) Regardless, I feel that clarification on the correctness of the practice of orginating a prefix in multiple ASes is called for. On this I agree with Philip: Philip> Not commenting on the rights and wrong, but if this is really Philip> a "MUST NOT" it needs to be documented as such. Thanks. Jay B. -- Jay Borkenhagen jayb(a)braeburn.org Disclaimer ---------- This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication represents the originator's personal views and opinions, which do not necessarily reflect those of the NSC Group. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify administrator(a)nscglobal.com.

1 0

Re: Routing parts of another LIR's PA block
by Bovio＠aol.com 01 Sep '00

01 Sep '00

In a message dated 8/31/00 7:59:51 PM W. Europe Daylight Time, randy(a)psg.com writes: Folks, I think there is a misunderstanding here: << this is not bgp spec. it is rfc 1930, see appended, and is not a MUST NOT. >> As you can see above Randy wrote that this is *NOT* a MUST NOT, and not the opposite as people seem to believe. Cheers

2 1

Routing parts of another LIR's PA block
by Jacques Caron 01 Sep '00

01 Sep '00

Hi, We have the usual case of a customer asking us to route a /24 out of somebody else's PA block, which I was about to send back to the customer (or at least have him ask for authorization from the "owner" of that range to have it routed as a more specific), but I wanted to give our support people the right RIPE document that says we're not allowed to do that, and I didn't find it... The docs I found (mainly ripe-185) talk about the assignment of the address space, but do not talk about the routing of such blocks. So, is there really a document saying so, or is a customer allowed to ask that as long as he keeps a contractual relationship with the other ISP that allows him to keep the address space? Any pointers welcome. Thanks, Jacques. --- Jacques Caron PSINetworks Europe Network Engineer PSINet Europe Regional Peering Coordinator Mail: Rue Friz-Courvoisier 103 - CH-2100 La Chaux-de-Fonds Phone: +41 32 967 5418

7 9

Re: Routing parts of another LIR's PA block
by Sascha E. Pollok 01 Sep '00

01 Sep '00

Jacques, >Note also that in the case of a multi-homed customer not using BGP, the >route would indeed appear in multiple ASes, and would require the other ISP >to announce its whole PA block _and_ the more specific for load-sharing to >occur... Indeed. I missed that point since we (before becoming a LIR) got an own AS-Number before having any own PA networks except the prefixes from our upstream. The difference there, of course, is the own AS-number. Since there ain't very much AS-numbers (as 2-byte counter, am I right?), no ISP should ever consider getting an own ASN for their to-be multihomed customers. Sure... >It looks to me like it should be prohibited to announce parts of a PA >block. If the customer needs to announce addresses via multiple providers, >he should switch to PI, shouldn't he? Sounds good for me. As long the customer doesn't have an own ASN. Imagine the setup of ISP1, Customer and ISP2. ISP1 has a /19. Customer has a /24 out of the /19. ISP2 is the new upstream to give redundancy / multihoming to Customer. ISP1 announces the /24 as addition to the /19 to their upstreams AND announces the /24 to ISP2. Most companies wouldn't do that because their customer is "Customer" and not ISP1. Anyway, this should work. What do you think? With that setup you wouldn't have inconsistent-ASes. Ok. Redundancy is a little bit complicated, that way. The BGP-speaking router of ISP1 should be physically located at "Customer". GNgh... that is getting too far. >Jacques. Sascha

1 0

IP allocs on the NAPs/IXs
by Berislav Todorovic 31 Aug '00

31 Aug '00

Hello, Apologies if this is a FAQ, but I really didn't find any site that contains a list of IP address allocations/assignments for various Internet exchange points worldwide. Is there any list of NAP addresses available? Such a thing would be useful to filter out leaking NAP address announcements from peers. Thanks in advance for any information! Regards, Beri --------- Berislav Todorovic, Network Engineer --------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri(a)kpnqwest.net <=> beri(a)EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. -----

1 0

RIPE NCC Region Weekly Routing Report
by Routing Analysis 31 Aug '00

31 Aug '00

This is an automated weekly mailing sent to the RIPE Routing WG e-mail list describing the state of the Internet Routing Table in Europe, Middle East and North Africa. Daily listings are sent to bgp-stats(a)lists.apnic.net For a graphical representation, please see http://www.apnic.net/stats/bgp. If you have any comments please contact Philip Smith <pfs(a)cisco.com>. Europe, Middle East, North Africa Report 01 Sep, 2000 Analysis Summary ---------------- BGP routing table entries examined: 87429 Origin ASes present in the Internet Routing Table: 8384 Origin ASes announcing only one prefix: 2836 Transit ASes present in the Internet Routing Table: 1162 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 15 Illegal AS announcements present in the Routing Table: 7 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 2 Number of addresses announced to Internet: 1168696612 Equivalent to 69 /8s, 168 /16s and 229 /24s Percentage of available address space announced: 31.5 Percentage of allocated address space announced: 61.8 Percentage of available address space allocated: 51.0 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 13597 Prefixes being announced from the RIPE address blocks: 10621 RIPE Region origin ASes present in the Internet Routing Table: 2248 RIPE Region origin ASes announcing only one prefix: 1085 RIPE Region transit ASes present in the Internet Routing Table: 441 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 15 Number of RIPE addresses announced to Internet: 75692392 Equivalent to 4 /8s, 130 /16s and 249 /24s Percentage of available RIPE address space announced: 64.5 RIPE AS Blocks 1877 - 1901, 2042, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 RIPE Address Blocks 62/8, 193/8, 194/7, 212/7 and 217/8 RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 3301 389 298 TeliaNet Sweden 1257 337 264 Swipnet AB 1270 249 397 UUNET Germany 1849 242 344 PIPEX 702 212 381 UUNET Technologies, Inc. 1275 185 906 DFN IP Service 786 181 959 JANET IP Service 719 178 145 LANLINK 5515 168 354 Sonera Finland 3320 157 316 Deutsche Telekom AG 517 153 183 Xlink 3215 131 133 RAIN 2609 128 4 EUnet-TN 9057 128 42 Level 3 public IP n 2856 125 263 BTnet UK Regional network 3303 121 277 Swisscom 8895 114 28 Saudi Arabia AS 1901 101 76 EUnet Austria 1267 93 955 IUnet S.p.A Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2013 5420 UUNET Technologies, Inc. 1 925 4519 BBN Planet 1221 920 976 Telstra 7018 809 3035 AT&T 705 789 41 UUNET Technologies, Inc. 2914 743 1363 Verio, Inc. 816 712 179 UUNET Canada4 1239 682 1593 Sprint ICM-Inria 7046 681 506 UUNET Technologies, Inc. 1785 668 811 Sprint ICM 3561 623 1520 Cable & Wireless USA 174 606 2765 PSINet Inc. 3549 495 428 Frontier GlobalCenter 271 469 380 BCnet Backbone 2764 463 130 connect.com.au pty ltd 209 455 531 Qwest 3908 446 277 Supernet, Inc. 3602 437 80 Sprint Canada 2548 411 519 Digital Express Group, Inc. List of Illegal AS's (Global) ----------------------------- Bad AS Designation Network Transit AS Description 18435 UNALLOCATED 63.102.178.0/23 701 UUNET Technologies, 18436 UNALLOCATED 63.147.24.0/22 701 UUNET Technologies, 18437 UNALLOCATED 63.163.130.0/24 701 UUNET Technologies, 64602 PRIVATE 63.236.57.0/24 209 Qwest 64601 PRIVATE 63.236.90.0/24 209 Qwest 18435 UNALLOCATED 206.137.4.0/22 6347 SAVVIS Communication 64605 PRIVATE 208.47.206.0/24 209 Qwest Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 90.0.0.252/32 1221 Telstra 220.10.56.0/24 3215 RAIN Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:22 /9:4 /10:5 /11:9 /12:26 /13:55 /14:177 /15:289 /16:6612 /17:920 /18:1801 /19:5855 /20:3585 /21:3725 /22:5640 /23:7540 /24:50365 /25:139 /26:187 /27:83 /28:68 /29:96 /30:118 /31:0 /32:108 End of report

1 0

PAM2001 Call For Papers
by Henk Uijterwaal (RIPE-NCC) 30 Aug '00

30 Aug '00

Passive & Active Measurement: PAM-2001 Call for papers A workshop on passive and active measurement techniques for high speed computer networks and the Internet Amsterdam, the Netherlands, April 23-24, 2001 Program Committee: Henk Uijterwaal RIPE-NCC, NL, Conference Chair Nevil Brownlee U.Auckland, NZ Randy Bush Verio, USA kc Claffy CAIDA, USA Les Cottrell SLAC, USA Geoff Huston Telstra, AU Daniel Karrenberg RIPE-NCC, NL Ian Graham U.Waikato, NZ Yasuichi Kitamura APAN, Japan Will Leland Telcordia, USA Tony McGregor U.Waikato, NZ Ronn Ritke NLANR, USA Rick Whitner Agilent, USA As the Internet has grown over the last decade the need for precise measurement of network traffic has become steadily more apparent; most of today's Internet Service Providers and many of their large network customers are collecting and analysing traffic data for the purposes of performance monitoring, network engineering and cost recovery, but the engineering quality of these measurements vary. A steadily growing number of research groups have been working in the areas of: - Active Measurements, i.e. sending test packets and observing their progress through the Internet, - Passive Measurements, i.e. observing actual traffic on 'live' networks, - Performance Metrics, i.e. developing measures or indicators which can be used to characterise traffic behavior, - Traffic Statistics, i.e. attempting to understand and develop models of 'real' Internet traffic, and - Visualisation, i.e. finding effective ways to display what's happening in a network. After the successful workshop PAM2000 in Hamilton, New Zealand, in April 2000, the RIPE NCC will be organising another workshop on this topic in Amsterdam in April 2001. Papers are invited from the research, provider and any other communities on topics in the areas above, or any other area of network traffic measurement. Areas of interest include, but are not limited to: 1. 'Experience' papers, which describe practical uses of measurements, especially in large networks. 2. Papers on modelling network traffic, in particular if they are backed up by measurements of real traffic. 3. Papers describing network research that can be applied to existing networks. Extended abstracts (about 500 words, plain ASCII preferred) must be submitted by e-mail to pam2001(a)ripe.net by 12 November 2000. Paper submissions must contain the following: paper title, full name(s) of the author(s), organisational affiliation(s) and 1 email address where the author(s) can be contacted. Abstracts will be reviewed and acceptance notified no later than 18 December 2001. Papers, maximum 15 printed pages, must be submitted electronically by 5 March 2001. Details of acceptable paper formats will be published on the conference web site, http://www.ripe.net/pam2001 There will be an opportunity for participants to present measurement equipment and software. Proposals for demonstrations (about 500 words, plain ASCII) should be sent by email to the conference chair at pam2001(a)ripe.net by 5 March 2001. The program committee is investigating the possibility of organising one or more tutorial sessions in conjunction with the conference. Proposals for tutorials (about 500 words, plain ASCII) should be sent by email to the conference chair by 12 November 2000. The workshop will be held at the Barbizon Golden Tulip hotel in Amsterdam. Special room rates will be available for the conference. The conference fee will be (approximately) 175 Euro (US$165). The exact conference fee and details on registration will be published on the workshop's web page late November. The conference fee will include a printed copy of the papers selected for presentation at the workshop. Papers selected for publication will also be published on the web. Important dates: * 12 November 2000: Deadline for abstracts * 18 December 2000: Notification of acceptance * 5 March 2001: Final papers due * 23-24 April 2001: Conference Contact information: * PAM 2001 c/o RIPE-NCC Singel 258 1016 AB Amsterdam The Netherlands * Phone: +31.20.5354444 * Fax: +31.20.5354445 * Email: pam2001(a)ripe.net * Webpage: http://www.ripe.net/pam2001 ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(a)ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780).

1 0