September 2000 - routing-wg - mailman.ripe.net

The Cidr Report
by Tony Bates 08 Sep '00

08 Sep '00

This is an auto-generated mail on Fri Sep 8 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 08Sep00 0) General Status Table History ------------- Date Prefixes 010900 85543 020900 85631 030900 85544 040900 85623 050900 85693 060900 85755 070900 85753 080900 85860 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 65.0.0.0/14 from AS6172 *** Bogus 65.128.0.0/14 from AS209 *** Bogus 65.132.0.0/15 from AS209 *** Bogus 65.134.0.0/17 from AS209 *** Bogus 65.134.128.0/19 from AS209 *** Bogus 65.228.9.0/24 from AS577 *** Bogus 66.4.0.0/17 from AS11686 *** Bogus 66.4.0.0/15 from AS11686 *** Bogus 66.4.128.0/17 from AS11686 *** Bogus 66.6.32.0/20 from AS701 *** Bogus 66.6.64.0/20 from AS14480 *** Bogus 66.6.96.0/20 from AS10970 *** Bogus 66.6.128.0/20 from AS3561 *** Bogus 66.6.192.0/20 from AS11282 *** Bogus 217.0.0.0/13 from AS3320 *** Bogus 217.8.0.0/20 from AS1299 *** Bogus 217.8.32.0/20 from AS3220 *** Bogus 217.8.160.0/20 from AS8246 *** Bogus 217.9.32.0/20 from AS2686 *** Bogus 217.9.96.0/20 from AS12658 *** Bogus 217.9.128.0/20 from AS12969 *** Bogus 217.9.224.0/20 from AS13124 *** Bogus 217.10.0.0/20 from AS1270 *** Bogus 217.10.64.0/20 from AS15594 *** Bogus 217.10.96.0/20 from AS5556 *** Bogus 217.10.128.0/20 from AS5378 *** Bogus 217.10.160.0/23 from AS15641 *** Bogus 217.10.162.0 from AS15641 *** Bogus 217.10.192.0 from AS12302 *** Bogus 217.11.0.0/20 from AS9034 *** Bogus 217.11.64.0/20 from AS702 *** Bogus 217.12.192.0/20 from AS15626 *** Bogus 217.13.32.0 from AS15629 *** Bogus 217.13.33.0 from AS15629 *** Bogus 217.13.34.0 from AS15629 *** Bogus 217.13.192.0/20 from AS9126 *** Bogus 217.14.64.0/20 from AS3303 *** Bogus 217.14.96.0/23 from AS13099 *** Bogus 217.14.128.0/20 from AS8851 *** Bogus 217.14.192.0/20 from AS3226 *** Bogus 217.117.117.0 from AS2007 *** Bogus 220.10.56.0 from AS3215 AS Summary ---------- Number of ASes in routing system: 8399 Number of ASes announcing only one prefix: 4770 (2647 cidr, 2123 classful) Largest number of cidr routes: 902 announced by AS701 Largest number of classful routes: 1058 announced by AS701 1) Gains by aggregating at the origin AS level --- 08Sep00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 425 150 275 64.7% BCnet Backbone AS1221 618 453 165 26.7% TELSTRA-AS AS9706 198 52 146 73.7% Pusan Metropolitan City Office of AS9269 174 44 130 74.7% Hong Kong CTI AS2609 128 8 120 93.8% EUnet-TN AS7657 318 206 112 35.2% The Internet Group Limited AS1785 466 357 109 23.4% AppliedTheory Communications AS816 506 400 106 20.9% UUNET Canada (ASN-UUNETCA-AS4) AS7046 370 264 106 28.6% COQUI-NET PRTC Internet AS7545 158 55 103 65.2% TPG Internet Pty Ltd AS9304 117 21 96 82.1% Hutchcity AS7496 126 35 91 72.2% Power Up AS4293 339 251 88 26.0% Internal ASN for C&W AS6429 200 114 86 43.0% FirstCom Internet AS4755 194 111 83 42.8% Videsh Sanchar Nigam Ltd. India AS174 533 450 83 15.6% Performance Systems International AS705 329 249 80 24.3% ALTERNET-AS AS6595 133 56 77 57.9% DODDSEUR AS3908 253 176 77 30.4% Supernet, Inc. AS577 251 178 73 29.1% Bell Backbone AS724 217 149 68 31.3% DLA-ASNBLOCK-AS AS7018 575 507 68 11.8% AT&T WorldNet Service Backbone AS4792 77 11 66 85.7% SK Telecom Co., Ltd. AS1727 151 86 65 43.0% MRMS-WEST AS5106 101 37 64 63.4% AADS-COLUMBUS AS3749 122 60 62 50.8% TECNET AS3602 297 239 58 19.5% Sprint Canada Inc. AS701 1058 1002 56 5.3% Alternet AS5102 75 21 54 72.0% AADS-CHAMPAIGN AS376 123 69 54 43.9% RISQ 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

RIPE NCC Region Weekly Routing Report
by Routing Analysis 07 Sep '00

07 Sep '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 08 Sep, 2000 Analysis Summary ---------------- BGP routing table entries examined: 87190 Origin ASes present in the Internet Routing Table: 8426 Origin ASes announcing only one prefix: 2843 Transit ASes present in the Internet Routing Table: 1155 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 16 Illegal AS announcements present in the Routing Table: 11 Non-routable prefixes present in the Routing Table: 1 Prefixes being announced from the IANA Reserved Address blocks: 1 Number of addresses announced to Internet: 1169561017 Equivalent to 69 /8s, 182 /16s and 21 /24s Percentage of available address space announced: 31.6 Percentage of allocated address space announced: 61.9 Percentage of available address space allocated: 51.0 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 13603 Prefixes being announced from the RIPE address blocks: 10610 RIPE Region origin ASes present in the Internet Routing Table: 2260 RIPE Region origin ASes announcing only one prefix: 1085 RIPE Region transit ASes present in the Internet Routing Table: 442 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 16 Number of RIPE addresses announced to Internet: 75991720 Equivalent to 4 /8s, 135 /16s and 138 /24s Percentage of available RIPE address space announced: 64.7 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 398 UUNET Germany 1849 238 303 PIPEX 702 218 431 UUNET Technologies, Inc. 786 180 959 JANET IP Service 719 177 137 LANLINK 1275 172 834 DFN IP Service 5515 170 354 Sonera Finland 517 153 182 Xlink 3320 151 315 Deutsche Telekom AG 3215 142 144 RAIN 9057 128 42 Level 3 public IP n 2609 127 4 EUnet-TN 2856 125 263 BTnet UK Regional network 3303 120 276 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 2012 5468 UUNET Technologies, Inc. 1 922 4519 BBN Planet 1221 920 976 Telstra 7018 834 3026 AT&T 2914 713 1343 Verio, Inc. 7046 683 515 UUNET Technologies, Inc. 1239 677 1585 Sprint ICM-Inria 1785 667 803 Sprint ICM 705 637 44 UUNET Technologies, Inc. 3561 622 1527 Cable & Wireless USA 174 604 2741 PSINet Inc. 3549 495 419 Frontier GlobalCenter 271 467 380 BCnet Backbone 2764 462 130 connect.com.au pty ltd 209 460 531 Qwest 3908 443 277 Supernet, Inc. 3602 437 80 Sprint Canada 4293 429 63 Cable & Wireless USA 816 427 177 UUNET Canada4 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 65500 PRIVATE 130.133.0.0/16 12732 V-SPAN 65500 PRIVATE 130.149.0.0/16 12732 V-SPAN 65500 PRIVATE 160.45.0.0/16 12732 V-SPAN 65500 PRIVATE 192.109.42.0/24 12732 V-SPAN 18435 UNALLOCATED 206.137.4.0/22 6347 SAVVIS Communication 18437 UNALLOCATED 207.247.21.0/24 1239 Sprint ICM-Inria 64605 PRIVATE 208.47.206.0/24 209 Qwest Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 169.254.0.0/16 705 UUNET Technologies, Inc. Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 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:179 /15:288 /16:6617 /17:923 /18:1796 /19:5869 /20:3612 /21:3711 /22:5644 /23:7528 /24:50097 /25:147 /26:188 /27:84 /28:70 /29:99 /30:120 /31:0 /32:97 End of report

1 0

Routing comment
by Morgan Dollard 06 Sep '00

06 Sep '00

Hello, In reading the IOS Essentials for ISP's PDF, ver 2.84 http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip i came across something I believe might need a little bit of clarification. I dont know if many ISP's use this method or not, but i find it particularly usefull. On page 29, under the Caveats section, specifically the routing protocols part, it is stated that : ". Routing Protocols. If a routing protocol needs to be run over this link, it is operationally much easier to use IP addresses. Don't use "ip unnumbered" if the customer is peering with you using BGP across the link, or if the link is an internal backbone link. Simply use a network with a /30 address mask. (Routing will work over unnumbered links but the extra management and operational complexity probably outweighs the small address space advantage gained.) " Using Ip unnumbered and BGP is something that works extremely well, in the following case. The wan interface is unnumbered to the ethernet interface. The ethernet interface is using a primary IP that is the one that should be configured on the WAN interface, and a secondary IP that is the LAN IP In most cases, the Provider will want to peer its BGP session to the IP it assigned the customer. This setup allows the BGP session to be peered to the Ethernet interface, which in turns leeds to an end to end point of failure, from the Ethernet Interface, to the Wan Interface. This succesfully allows the ISP to monitor the customer's network availability without the use of piningin methods, and relying solely upon the well being of the BGP session. If this message is off list topic, i apologize for the inconvenience. Morgan Dollard 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.

4 3

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:40 To: Morgan Dollard Cc: 'routing-wg(a)ripe.net' Subject: Re: Routing comment At Mon, 4 Sep 2000, owner-routing-wg(a)ripe.net wrote: >In most cases, the Provider will want to peer its BGP session to the IP it >assigned the customer. This setup allows the BGP session to be peered to the >Ethernet interface, which in turns leeds to an end to end point of failure, >from the Ethernet Interface, to the Wan Interface. This succesfully allows >the ISP to monitor the customer's network availability without the use of >piningin methods, and relying solely upon the well being of the BGP session. >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? 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: Electrons on a bender 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.

3 2

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