Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07874; 1 Nov 95 5:18 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07870; 1 Nov 95 5:18 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa05370; 1 Nov 95 5:18 EST Received: from plaza.aarnet.EDU.AU (plaza.aarnet.edu.au [139.130.23.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id TAA04481 for ; Wed, 1 Nov 1995 19:59:09 +1100 Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by plaza.aarnet.EDU.AU (8.6.8/8.6.5) with ESMTP id TAA26301 for ; Wed, 1 Nov 1995 19:59:07 +1100 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id AAA27141; Wed, 1 Nov 1995 00:49:29 -0800 Date: Wed, 1 Nov 1995 00:49:29 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199511010849.AAA27141@greatdane.cisco.com> To: cidrd@iepg.org Subject: Last Call on "Ownership" Folks, The last call on "Ownership" has now successfully concluded. Several comments were received which require some fairly extensive editorial changes. We will proceed with the hum when we have a revised draft available. Watch this space... ;-) Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08564; 1 Nov 95 6:35 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08560; 1 Nov 95 6:35 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa06357; 1 Nov 95 6:35 EST Received: from rype.runit.sintef.no (rype.runit.sintef.no [129.241.100.108]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id VAA06336 for ; Wed, 1 Nov 1995 21:55:42 +1100 Received: from runit.sintef.no (localhost [127.0.0.1]) by rype.runit.sintef.no (8.6.11/8.6.9) with ESMTP id LAA10981; Wed, 1 Nov 1995 11:52:38 +0100 Message-Id: <199511011052.LAA10981@rype.runit.sintef.no> To: rgm3@is.chrysler.com Cc: pferguso@cisco.com, cidrd@iepg.org Subject: Re: RFC 1122 section 3.2.1.3 and CIDR Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Havard.Eidnes@runit.sintef.no In-Reply-To: Your message of "Tue, 31 Oct 1995 10:23:08 -0500" References: <9510311524.AA15537@clhubgw1.is.chrysler.com> X-Mailer: Mew beta version 0.96 on Emacs 19.29.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 01 Nov 1995 11:52:37 +0100 X-Orig-Sender: he@runit.sintef.no > Of course the local net is not running a classless routing > protocol. What year do you think this is, 2020? > > Actually, right now everything is static [...] Static routes can be classless, there is no contradiction between doing static and classless routing. > [...] and right; use of default gateway becuase no router > discovery (what ever for, right :( ). I reviewed the routing > tables on the OS/2, RS/6000 and Ascend 25. It is just that IBM > says, gee my mask is 255.255.255.192. My address is a class C, > ergo only addresses 65 - 190 (excluding 127 and 128) are > accessable by me. And nothing goes out the interface. It > doesn't even try. MVS TCP does it the same way, I got burnt > bad on that one 2 years ago. Let me see if I understand this correctly. Your client systems are on IP subnets with "legal" addresses according to the old interpretation, ie. either within 64-127 or 128-191. Your name server is on a different subnet which is numbered somewhere in the range 0-63 (possibly with a different mask), and there is a router between the client subnets and the subnet where the name server is located. What you are claiming is that the client systems refuse to even try to send IP packets to the name server system, right? This is presumably because the client system software "knows" that the name server is on "subnet zero", and that is "illegal". I think the key here is that the client systems have no business making the assumption that the subnet mask is identical for all subnets of a traditional network number. Routing is to be performed by the routers, not by the hosts, and I think you can use the section from RFC1122 (under 1.1.2) which states (c) Routing complexity should be in the gateways. Routing is a complex and difficult problem, and ought to be performed by the gateways, not the hosts. An important objective is to insulate host software from changes caused by the inevitable evolution of the Internet routing architecture. to argue this point. If the vendor claims that he has "embedded gateway functionality" (see section 1.1.4) in his product, you can point out the "con" argument under "DISCUSSION" of that point that in that case the vendor needs to more carefully follow the development on the routing side (and if that is the case he has obviously not been keeping up). Also see section 1.2.1 "Continuing Internet Evolution". You could also attack this via another angle: where in the host requirements is it said that a host under "Gateway selection" (section 3.3.1.2) is to discard datagrams based on the "legality" of the destination address? I claim that this part of the procedure is not listed, and note that instead it says: When there is no route cache entry for the destination host address (and the destination is not on the connected network), the IP layer MUST pick a gateway from its list of "default" gateways. > I plan on putting a sniffer on the net tomorrow, not going to > trust just general interface stats. Ok. Let's hear what you find out. - H=E5vard   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08909; 1 Nov 95 7:13 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08905; 1 Nov 95 7:13 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa06827; 1 Nov 95 7:13 EST Received: from pilot.firewall.is.chrysler.com (pilot.is.chrysler.com [204.189.94.147]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id WAA06860 for ; Wed, 1 Nov 1995 22:30:41 +1100 Received: by pilot.firewall.is.chrysler.com; id GAA13251; Wed, 1 Nov 1995 06:39:45 -0500 Received: from clhubgw1.is.chrysler.com(172.29.128.203) by pilot.is.chrysler.com via smap (g3.0.1) id sma013239; Wed, 1 Nov 95 06:39:35 -0500 Received: from rgm3.is.chrysler.com by clhubgw1.is.chrysler.com (5.x/SMI-4.1) id AB20805; Wed, 1 Nov 1995 06:30:26 -0500 Message-Id: <9511011130.AB20805@clhubgw1.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 01 Nov 1995 06:28:44 -0500 To: Tony Li Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Moskowitz Subject: Re: RFC 1122 section 3.2.1.3 and CIDR Cc: pferguso@cisco.com, cidrd@iepg.org At 02:29 PM 10/31/95 -0800, Tony Li wrote: > >Note that the correct 'hack' to fix this is to lie to the host and >tell it that the class C is not subnetted. Proxy arp from your local >router saves you... Proxy ARPs, shudder..... Paul is right, hack and lie are indeed the operative words here. Robert Moskowitz Chrysler Corporation (810) 758-8212   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09217; 1 Nov 95 7:56 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09212; 1 Nov 95 7:56 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa07381; 1 Nov 95 7:56 EST Received: from venera.isi.edu (venera.isi.edu [128.9.0.32]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id XAA07403 for ; Wed, 1 Nov 1995 23:09:55 +1100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bmanning@isi.edu Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 1 Nov 1995 04:09:52 -0800 Posted-Date: Wed, 1 Nov 1995 04:06:18 -0800 (PST) Message-Id: <199511011206.AA04834@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 1 Nov 1995 04:06:19 -0800 Subject: Re: RFC 1122 section 3.2.1.3 and CIDR To: Tony Li Date: Wed, 1 Nov 1995 04:06:18 -0800 (PST) Cc: rgm3@is.chrysler.com, pferguso@cisco.com, cidrd@iepg.org In-Reply-To: <199510312229.OAA26629@greatdane.cisco.com> from "Tony Li" at Oct 31, 95 02:29:41 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 269 > > > Note that the correct 'hack' to fix this is to lie to the host and > tell it that the class C is not subnetted. Proxy arp from your local > router saves you... > > Tony > hack, lie, proxy-arp.... The things we do for backward compatability..:) -- --bill   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09363; 1 Nov 95 8:09 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09359; 1 Nov 95 8:09 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa07578; 1 Nov 95 8:09 EST Received: from munnari.oz.au (munnari.OZ.AU [128.250.22.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id XAA07467 for ; Wed, 1 Nov 1995 23:13:51 +1100 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18210; Wed, 1 Nov 1995 23:13:35 +1100 (from kre@munnari.OZ.AU) To: Havard.Eidnes@runit.sintef.no Cc: cidrd@iepg.org Subject: Re: RFC 1122 section 3.2.1.3 and CIDR In-Reply-To: Your message of "Wed, 01 Nov 1995 11:52:37 BST." <199511011052.LAA10981@rype.runit.sintef.no> Date: Wed, 01 Nov 1995 23:12:53 +1100 Message-Id: <125.815227973@munnari.OZ.AU> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Elz Date: Wed, 01 Nov 1995 11:52:37 +0100 From: Havard.Eidnes@runit.sintef.no Message-ID: <199511011052.LAA10981@rype.runit.sintef.no> Tony already gave the practical solution to this, so most of the rest of this discussion is (or should be) academic, and probably belongs on ietf-hosts rather than cidrd, but never mind, this is where it is... I think the key here is that the client systems have no business making the assumption that the subnet mask is identical for all subnets of a traditional network number. I think I agree, but the actions of these hosts can actually be defended based on basic IETF principles and standards. There certainly used to be an assumption that a classful net would have a single net mask, and the rules did clearly say that the subnet numbers with values of all zero or all one bits were illegal. Add to that the general principle of being conservative in what you send, and it is arguable that a host should make sure it is not sending to any address it can deduce is illegal, sending to illegal addresses is hardly conservative. It turns out that this isn't what we want hosts to do these days, but that doesn't mean that doing it is totally unreasonable. Finally, to add just a little value to this message, I might add to Tony's recommendation ("lie about the subnet mask") that if you do this, which usually works, also be sure to use the limited broadcast address on the cable, rather than the subnet directed broadcast (ie: 255.255.255.25 rather than ..all-ones). Using the latter can cause some interesting problems when hosts don't agree as to just how many 1's need to be included. kre   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09608; 1 Nov 95 8:23 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09604; 1 Nov 95 8:23 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa07804; 1 Nov 95 8:23 EST Received: from pilot.firewall.is.chrysler.com (pilot.is.chrysler.com [204.189.94.147]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id XAA07784 for ; Wed, 1 Nov 1995 23:32:10 +1100 Received: by pilot.firewall.is.chrysler.com; id HAA13367; Wed, 1 Nov 1995 07:41:14 -0500 Received: from clhubgw1.is.chrysler.com(172.29.128.203) by pilot.is.chrysler.com via smap (g3.0.1) id sma013361; Wed, 1 Nov 95 07:41:13 -0500 Received: from rgm3 (rgm3.is.chrysler.com) by clhubgw1.is.chrysler.com (5.x/SMI-4.1) id AA20936; Wed, 1 Nov 1995 07:32:03 -0500 Message-Id: <9511011232.AA20936@clhubgw1.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 01 Nov 1995 07:30:20 -0500 To: Havard.Eidnes@runit.sintef.no Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Moskowitz Subject: Re: RFC 1122 section 3.2.1.3 and CIDR Cc: pferguso@cisco.com, cidrd@iepg.org At 11:52 AM 11/1/95 +0100, Havard.Eidnes@runit.sintef.no wrote: > >Let me see if I understand this correctly. Your client systems >are on IP subnets with "legal" addresses according to the old >interpretation, ie. either within 64-127 or 128-191. Your name >server is on a different subnet which is numbered somewhere in >the range 0-63 (possibly with a different mask), and there is a >router between the client subnets and the subnet where the name >server is located. What you are claiming is that the client >systems refuse to even try to send IP packets to the name server >system, right? This is presumably because the client system >software "knows" that the name server is on "subnet zero", and >that is "illegal". > >I think the key here is that the client systems have no business >making the assumption that the subnet mask is identical for all >subnets of a traditional network number. Routing is to be >performed by the routers, not by the hosts, and I think you can >use the section from RFC1122 (under 1.1.2) which states > rest deleted for brevity. This is a good proposal, and I will bludgeon the vendor with it (I have bludgeoned this vendore many times in the past with mixed results). But here is the crux of their argument: IP addresses are not permitted to have the value 0 or -1 for any of the , , or fields (except in the special cases listed above). This implies that each of these fields will be at least two bits long. So if these addresses are not 'permitted', why deal with them. Of course the main rebuttle is variable subnet masks in an OSPF network (btw, todate, this one has NOT produced results). Just becuase the source system 'thinks' the address is not permitted, does not mean it is not permitted. Let the gateways decide that, as you said. Robert Moskowitz Chrysler Corporation (810) 758-8212   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10439; 1 Nov 95 9:00 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10435; 1 Nov 95 9:00 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa08466; 1 Nov 95 9:00 EST Received: from rype.runit.sintef.no (rype.runit.sintef.no [129.241.100.108]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id XAA08307 for ; Wed, 1 Nov 1995 23:59:16 +1100 Received: from runit.sintef.no (localhost [127.0.0.1]) by rype.runit.sintef.no (8.6.11/8.6.9) with ESMTP id NAA11667; Wed, 1 Nov 1995 13:56:16 +0100 Message-Id: <199511011256.NAA11667@rype.runit.sintef.no> To: rgm3@is.chrysler.com Cc: pferguso@cisco.com, cidrd@iepg.org Subject: Re: RFC 1122 section 3.2.1.3 and CIDR Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Havard.Eidnes@runit.sintef.no In-Reply-To: Your message of "Wed, 01 Nov 1995 07:30:20 -0500" References: <9511011232.AA20936@clhubgw1.is.chrysler.com> X-Mailer: Mew beta version 0.96 on Emacs 19.29.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 01 Nov 1995 13:56:15 +0100 X-Orig-Sender: he@runit.sintef.no > This is a good proposal, and I will bludgeon the vendor with it (I have > bludgeoned this vendore many times in the past with mixed results). But > here is the crux of their argument: > > IP addresses are not permitted to have the value 0 or -1 for > any of the , , or number> fields (except in the special cases listed above). > This implies that each of these fields will be at least two > bits long. > > So if these addresses are not 'permitted', why deal with them. Hm, this is going into interpretation and not direct citation of the HR RFCs, but I think that given the other quotes I cited from this document it should be safe to assume that this requirement only applies locally for each subnet, and thus in the context of a given host, to the combination of IP address/subnet mask for the directly connected interface(s) of the host. Again, a host has no business making assumptions about addresses and the legality of them when they are beyond the directly connected subnet(s). > Of course the main rebuttle is variable subnet masks in an OSPF > network (btw, todate, this one has NOT produced results). The main rebuttal is "variable-length subnet masks" irrespective of the method used to set up the routing tables (it could be static or it could be any dynamic routing protocol with VLSM support). It is perhaps also worth mentioning that even RFC1009, dated June 1987 (!) contains this text: Flexible use of the available address space will be increasingly important in coping with the anticipated growth of the Internet. Thus, we allow a particular subnetted network to use more than one subnet mask. Several campuses with very large LAN configurations are also creating nested hierarchies of subnets, sub-subnets, etc. Perhaps it's time to at least conform to standards specified in 8-year old documents? ;-) (Not to speak of the general architecture with the host/gateway functionality split which goes even further back.) > Just becuase the source system 'thinks' the address is not > permitted, does not mean it is not permitted. Let the gateways > decide that, as you said. Exactly. Besides, the source system has no business 'thinking' this. - H=E5vard   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21190; 1 Nov 95 16:28 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21186; 1 Nov 95 16:28 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa17504; 1 Nov 95 16:28 EST Received: from chico.rediris.es (chico.rediris.es [130.206.1.3]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id GAA13271 for ; Thu, 2 Nov 1995 06:32:07 +1100 Received: by chico.rediris.es (8.6.12/SMI-SVR4) id SAA11508; Wed, 1 Nov 1995 18:31:27 -0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Miguel A. Sanz. RedIRIS/CSIC" Message-Id: <9511012031.ZM11504@unknown.zmail.host> Date: Wed, 1 Nov 1995 20:31:26 +0100 In-Reply-To: Hank Nussbacher "Intermittent route table analysis" (Nov 1, 11:54) References: <199511011001.JAA02773@chico.rediris.es> X-Mailer: Z-Mail (3.2.0 06sep94) To: Hank Nussbacher , cidrd@iepg.org Subject: Re: Intermittent route table analysis Cc: rsh@britain.eu.net, gjh@britain.eu.net, bilse@eu.net, miguel.sanz@rediris.es, ncc@tip.net, net-ops@bt.net, noc@inet.it, sven@upsys.se Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19511012031.ZM11504.unknown.zmail.host" --PART-BOUNDARY=.19511012031.ZM11504.unknown.zmail.host Content-Description: Text Content-Type: text/plain ; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Zm-Decoding-Hint: mimencode -q -u On Nov 1, 11:54, Hank Nussbacher wrote: > Subject: Intermittent route table analysis > Routes with prefix longer than /24: > > 131.116.136.0/26 192.121.154.25 100 0 3300 ?=BA > 131.116.136.64/26 192.121.154.25 100 0 3300 ?=BA > 131.116.136.128/26 192.121.154.25 100 0 3300 ? > 147.186.219.64/26 192.121.154.25 20 100 0 2874 i=BA > 193.144.233.0/25 194.72.26.141 0 5400 766 i=BA= > 193.144.233.128/25 194.72.26.141 0 5400 766 i Unfortunatedly RedIRIS has to inject these last two routes as a way to counteract the repeated misannouncement of 193.144.233.0/24 by AS1290 (Eunet GB). At least until they reply to the couple of messages I sent to them asking for an investigation/explanation/confirmation-it- won't-be-repeated-ever-again. > 194.20.7.4/30 192.121.154.25 100 0 3300 3302 331= 3 ?=BA > 194.72.27.0/30 194.72.26.141 0 5400 ?=BA > 200.255.253.32/27 192.121.156.41 100 0 1800 1239 179= 0 4230 i=BA > 200.255.253.240/28 192.121.156.41 100 0 1800 1239 179= 0 4230 i Regards, Miguel __________________ __ ___________________= ___ /_/ Miguel A. Sanz __ __ Email: miguel.sanz@rediris= =2Ees RedIRIS/CSIC /_/ RedIRIS /_/ Tel: + 34 1 5855= 152 Serrano 142 __ Fax: + 34 1 5855= 146 E-28006 Madrid /_/ SPAIN INTERNET SERVICE MANAGEM= ENT ____________ Spanish Academic & Research Network ________________________= ___ --PART-BOUNDARY=.19511012031.ZM11504.unknown.zmail.host--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05945; 2 Nov 95 0:50 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05939; 2 Nov 95 0:50 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa02115; 2 Nov 95 0:49 EST Received: from vp.netgate.net (vp.netgate.net [204.145.147.18]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id PAA25028 for ; Thu, 2 Nov 1995 15:14:22 +1100 Received: from [204.145.147.66] (d46.netgate.net [204.145.147.66]) by vp.netgate.net (8.6.12/8.6.9) with ESMTP id UAA25909; Wed, 1 Nov 1995 20:25:31 -0800 X-Sender: dcrocker@pop.netgate.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 1 Nov 1995 20:14:13 -0800 To: Tony Li Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker Subject: Re: Last Call on "Ownership" Cc: cidrd@iepg.org At 12:49 AM 11/1/95, Tony Li wrote: >comments were received which require some fairly extensive editorial Which comments and what sorts of changes? d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale, CA 94086 USA http://users.aimnet.com/~dcrocker/ *** Email address is changed from the *** long-standing stanford mailbox   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07025; 2 Nov 95 3:08 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07021; 2 Nov 95 3:08 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa03968; 2 Nov 95 3:08 EST Received: from plaza.aarnet.EDU.AU (plaza.aarnet.edu.au [139.130.23.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id QAA28018 for ; Thu, 2 Nov 1995 16:56:25 +1100 Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by plaza.aarnet.EDU.AU (8.6.8/8.6.5) with ESMTP id QAA23741 for ; Thu, 2 Nov 1995 16:55:58 +1100 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id VAA21280; Wed, 1 Nov 1995 21:54:30 -0800 Date: Wed, 1 Nov 1995 21:54:30 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199511020554.VAA21280@greatdane.cisco.com> To: dcrocker@brandenburg.com Cc: cidrd@iepg.org In-Reply-To: (message from Dave Crocker on Wed, 1 Nov 1995 20:14:13 -0800) Subject: Re: Last Call on "Ownership" >comments were received which require some fairly extensive editorial Which comments and what sorts of changes? Comments which remarked on the grammatical competence of the authors. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09311; 2 Nov 95 6:37 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09307; 2 Nov 95 6:37 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa06708; 2 Nov 95 6:37 EST Received: from VM.TAU.AC.IL (taunivm.tau.ac.il [132.66.32.4]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id VAA01252 for ; Thu, 2 Nov 1995 21:16:42 +1100 Message-Id: <199511021016.VAA01252@nico.aarnet.edu.au> Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 3048; Thu, 02 Nov 95 12:15:04 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 1179; Thu, 2 Nov 1995 12:15:04 +0200 Date: Thu, 02 Nov 95 12:13:26 IST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hank Nussbacher Subject: NTI bought by cisco To: cidrd@iepg.org MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Just heard that Network Translation - which makes a NAT for IP address translation has been bought out by Cisco. :-) Hank   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12052; 2 Nov 95 9:29 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12047; 2 Nov 95 9:29 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa09534; 2 Nov 95 9:29 EST Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id AAA03442 for ; Fri, 3 Nov 1995 00:05:57 +1100 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id FAA04935; Thu, 2 Nov 1995 05:05:52 -0800 Message-Id: <199511021305.FAA04935@hubbub.cisco.com> To: Tony Li cc: cidrd@iepg.org Subject: Re: Last Call on "Ownership" In-reply-to: Your message of "Wed, 01 Nov 95 21:54:30 PST." <199511020554.VAA21280@greatdane.cisco.com> Date: Thu, 02 Nov 95 05:05:35 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Yakov Rekhter Tony, > >comments were received which require some fairly extensive editorial > > Which comments and what sorts of changes? > > Comments which remarked on the grammatical competence of the authors. And I am willing (and should) take all the blame for the grammatical incompetence... Yakov.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13607; 2 Nov 95 10:28 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13602; 2 Nov 95 10:28 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa10740; 2 Nov 95 10:28 EST Received: from aimnet.com (aimnet.aimnet.com [204.247.0.100]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id BAA04421 for ; Fri, 3 Nov 1995 01:11:36 +1100 Received: from [204.145.147.51] (d31.netgate.net [204.145.147.51]) by aimnet.com (8.6.12/8.6.12) with ESMTP id GAA21043; Thu, 2 Nov 1995 06:05:22 -0800 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 2 Nov 1995 06:10:00 -0800 To: Tony Li Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker Subject: Re: Last Call on "Ownership" Cc: cidrd@iepg.org At 9:54 PM 11/1/95, Tony Li wrote: >Comments which remarked on the grammatical competence of the authors. Oh so some, folks thought that, there was a problem with, the grammar? it certainly; seemed fine to me. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale, CA 94086 USA http://users.aimnet.com/~dcrocker/ *** Email address is changed from the *** long-standing stanford mailbox   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23567; 2 Nov 95 17:07 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23563; 2 Nov 95 17:07 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa21189; 2 Nov 95 17:07 EST Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id IAA08570 for ; Fri, 3 Nov 1995 08:19:41 +1100 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id NAA04572; Thu, 2 Nov 1995 13:19:36 -0800 Date: Thu, 2 Nov 1995 13:19:36 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199511022119.NAA04572@greatdane.cisco.com> To: yakov@cisco.com Cc: cidrd@iepg.org In-Reply-To: <199511021305.FAA04935@hubbub.cisco.com> (message from Yakov Rekhter on Thu, 02 Nov 95 05:05:35 PST) Subject: Re: Last Call on "Ownership" And I am willing (and should) take all the blame for the grammatical incompetence... The responsibility is that of all authors. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09471; 3 Nov 95 6:55 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09467; 3 Nov 95 6:55 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa07078; 3 Nov 95 6:55 EST Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id VAA03259 for ; Fri, 3 Nov 1995 21:46:03 +1100 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id CAA12796; Fri, 3 Nov 1995 02:45:56 -0800 Date: Fri, 3 Nov 1995 02:45:56 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199511031045.CAA12796@greatdane.cisco.com> To: cidrd@iepg.org Subject: Agenda Tentative Agenda: - Report on address space utilization (Tli, Frank S.) - Report on routing table grown (Erik-Jan) - Report on class A space utilization and class A CIDRization (Manning) - Charging for advertisements (Yakov) - Document movement - Appeal to return addresses (to BCP) - RFC 1597bis (to BCP) - Address ownership If you have a topic that you would like placed on the agenda, please contact me. Thanks, Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12175; 4 Nov 95 14:38 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12171; 4 Nov 95 14:38 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa12711; 4 Nov 95 14:38 EST Received: from VM.TAU.AC.IL (taunivm.tau.ac.il [132.66.32.4]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id FAA16194 for ; Sun, 5 Nov 1995 05:58:28 +1100 Message-Id: <199511041858.FAA16194@nico.aarnet.edu.au> Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 1240; Sat, 04 Nov 95 20:57:01 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 5645; Sat, 4 Nov 1995 20:57:01 +0200 Date: Sat, 04 Nov 95 20:52:12 IST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hank Nussbacher Subject: New book on routing To: cidrd@iepg.org MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT I just read over the weekend a new book called "Routing in the Internet" by Christian Huitema. The book covers IGPs (RIP and OSPF in detail and a little on IGRP), EGPs (BGP, CIDR), Multicasting, Mobility and Resource Reservation. For someone bringing online new personnel into handling routing, as well as a good reference piece for those who "know it all", I highly recommend this book. The book is published by Prentice Hall and is 315 pages. Hank   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12348; 4 Nov 95 14:57 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ab12342; 4 Nov 95 14:57 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa18479; 4 Nov 95 14:57 EST Received: from dune.silkroad.com (dune.silkroad.com [165.209.1.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id GAA17855 for ; Sun, 5 Nov 1995 06:26:30 +1100 Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id OAA30679; Sat, 4 Nov 1995 14:23:59 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Bass Message-Id: <199511041923.OAA30679@dune.silkroad.com> Subject: Re: New book on routing To: Hank Nussbacher Date: Sat, 4 Nov 1995 14:23:59 -0500 (EST) Cc: cidrd@iepg.org In-Reply-To: <199511041858.FAA16194@nico.aarnet.edu.au> from "Hank Nussbacher" at Nov 4, 95 08:52:12 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1504 Actually, _Routing in the Internet_ was published in early 1995. I remember reading it when it first came off the press and was very impressed with Christian's writing style. His humor and internetworking perspective is quite remarkable. I especially enjoyed his chapter 10 on Policy Routing, IDRP, IDPR, and AS-Level Maps. Chapter 9, BTW is entitled "CIDR and the Routing Explosion" and cites references by V. Fuller, T. Li, K. Varadhan, Y. Rekhter, E. Gerich and P. Gross. ISBN: 0-13-132192-7 Also, BTW does IPv6 specifications have hooks for developing AS level routing protocols? I printed out the IPv6 draft the other day and did not immediately see reference to this. Did I miss something in my incomplete reading scan, as usual? I know that CIDRD-WG is not the right group to ask this, but given the brain power here, could someone address this? Thanks, Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12717; 4 Nov 95 15:41 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12713; 4 Nov 95 15:41 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa01816; 4 Nov 95 15:41 EST Received: from lint.cisco.com (lint.cisco.com [171.68.235.77]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id HAA20488 for ; Sun, 5 Nov 1995 07:10:15 +1100 Received: from pferguso-pc.cisco.com (sl-chanty-02.cisco.com [171.69.126.156]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id MAA04672; Sat, 4 Nov 1995 12:09:42 -0800 Date: Sat, 4 Nov 1995 12:09:42 -0800 Message-Id: <199511042009.MAA04672@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Tim Bass Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Paul Ferguson Subject: Re: New book on routing Cc: cidrd@iepg.org Tim, Define 'hooks.' :-) One of the 'improvements' over IPv4 is due to the 128 bit address length, which accommodates some interesting possibilities for expanded routing options. It is my understanding that, at least in the beginning of deployment, IPv6 is not really designed to take any really radical steps away from IPv4. Also, not sure if you've seen it yet, but another book, "IPng, Internet Protocol Next Generation," edited by Scott Bradner & Allison Mankin, contains a handy collection of IETF historical & proposal documents, to include a technical overview of IPv6. The ISBN number is 0-201-63395-7. Cheers, - paul At 02:23 PM 11/4/95 -0500, Tim Bass wrote: > >Actually, _Routing in the Internet_ was published in early >1995. I remember reading it when it first came off the press >and was very impressed with Christian's writing style. >His humor and internetworking perspective is quite remarkable. > >I especially enjoyed his chapter 10 on Policy Routing, IDRP, >IDPR, and AS-Level Maps. Chapter 9, BTW is entitled >"CIDR and the Routing Explosion" and cites references by >V. Fuller, T. Li, K. Varadhan, Y. Rekhter, E. Gerich and P. Gross. > >ISBN: 0-13-132192-7 > >Also, BTW does IPv6 specifications have hooks for developing AS >level routing protocols? I printed out the IPv6 draft the other >day and did not immediately see reference to this. Did I >miss something in my incomplete reading scan, as usual? >I know that CIDRD-WG is not the right group to ask this, but >given the brain power here, could someone address this? > > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso@cisco.com c i s c o S y s t e m s   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13471; 4 Nov 95 17:06 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13467; 4 Nov 95 17:06 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa27388; 4 Nov 95 17:06 EST Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id IAA25899 for ; Sun, 5 Nov 1995 08:38:03 +1100 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id QAA26562; Sat, 4 Nov 1995 16:37:11 -0500 (EST) Date: Sat, 4 Nov 1995 16:37:11 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Scott Bradner Message-Id: <199511042137.QAA26562@newdev.harvard.edu> To: bass@dune.silkroad.com, HANK@taunivm.tau.ac.il Subject: Re: New book on routing Cc: cidrd@iepg.org Tim, > BTW does IPv6 specifications have hooks for developing AS > level routing protocols? The SDRP working group produced an IPv6 version of the SDRP spec (called ERP). When the spec is mature I would expect it to become one of the normal IPv6 routing protocols. Other than that, I'm not sure what sort of hooks you might have in mind. Scott   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14038; 4 Nov 95 18:23 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14034; 4 Nov 95 18:23 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa20720; 4 Nov 95 18:23 EST Received: from dune.silkroad.com (dune.silkroad.com [165.209.1.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id JAA29843 for ; Sun, 5 Nov 1995 09:41:47 +1100 Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id RAA31866; Sat, 4 Nov 1995 17:38:45 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Bass Message-Id: <199511042238.RAA31866@dune.silkroad.com> Subject: Re: New book on routing To: Scott Bradner Date: Sat, 4 Nov 1995 17:38:45 -0500 (EST) Cc: HANK@taunivm.tau.ac.il, cidrd@iepg.org In-Reply-To: <199511042137.QAA26562@newdev.harvard.edu> from "Scott Bradner" at Nov 4, 95 04:37:11 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2138 Scott: This might be moving into shark infested waters, but I'll gladly dive in dangerous waters :-) .... you asked 'what hook' in IPv6 I was thinking about.... I was wondering if the current IPv6 specifications are being build to support *specific* inter-domain routing protocols or if IPv6 will have specific fields, such as fields for the AS origin and destinations. ( ..... this is not a trivial question on 128 bit address space, thanks, I think we can safely assume there will be bigger address space ;-). I was under the impression that IPv6 was getting close to the finish line and I am interested to discover *if* the AS information will be included in the IP header: i.e the AS origin and destination? This is probally not the right WG to ask this; but, I do appreciate the discussion or a pointer to where to forward this question. Regards, Tim PS: On Paul's question on the latest IPv6 book edited by Scott... Yes, I have a copy... love the "outer space" cover photo... but to be quite honest, I've taken a short break from techie books and have not read the ... 'Next Generation' book ( it's on my bookshelf).... I'm currently reading one of the funniest books I have ever read... _A Confederacy of Dunces_ by Toole, published after Toole's death and winner of a Pulitzer Prize in the 80's. It is a riot about this big fat odd character named Ignatius, of all things, set in New Orleans.... funny, funny, book and an easy, light read. I'll get to Scott's book before the leaves fall :-) -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14186; 4 Nov 95 18:41 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14182; 4 Nov 95 18:41 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa26242; 4 Nov 95 18:41 EST Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id KAA01841 for ; Sun, 5 Nov 1995 10:12:23 +1100 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id SAA26773; Sat, 4 Nov 1995 18:11:37 -0500 (EST) Date: Sat, 4 Nov 1995 18:11:37 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Scott Bradner Message-Id: <199511042311.SAA26773@newdev.harvard.edu> To: bass@dune.silkroad.com, sob@newdev.harvard.edu Subject: Re: New book on routing Cc: cidrd@iepg.org, HANK@taunivm.tau.ac.il   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15161; 4 Nov 95 20:54 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15157; 4 Nov 95 20:54 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa06678; 4 Nov 95 20:54 EST Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id MAA10567 for ; Sun, 5 Nov 1995 12:26:37 +1100 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id RAA02120; Sat, 4 Nov 1995 17:25:51 -0800 Date: Sat, 4 Nov 1995 17:25:51 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199511050125.RAA02120@greatdane.cisco.com> To: sob@newdev.harvard.edu Cc: bass@dune.silkroad.com, HANK@taunivm.tau.ac.il, cidrd@iepg.org In-Reply-To: <199511042137.QAA26562@newdev.harvard.edu> (message from Scott Bradner on Sat, 4 Nov 1995 16:37:11 -0500 (EST)) Subject: Re: New book on routing The SDRP working group produced an IPv6 version of the SDRP spec (called ERP). When the spec is mature I would expect it to become one of the normal IPv6 routing protocols. Assuming, of course, that there's enough customer demand that we can even find three implementations. This appears to be a problem that people only want solved theoretically... Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15185; 4 Nov 95 20:55 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15181; 4 Nov 95 20:55 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa07023; 4 Nov 95 20:55 EST Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id MAA10326 for ; Sun, 5 Nov 1995 12:23:05 +1100 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id RAA02081; Sat, 4 Nov 1995 17:22:34 -0800 Date: Sat, 4 Nov 1995 17:22:34 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199511050122.RAA02081@greatdane.cisco.com> To: bass@dune.silkroad.com Cc: sob@newdev.harvard.edu, HANK@taunivm.tau.ac.il, cidrd@iepg.org In-Reply-To: <199511042238.RAA31866@dune.silkroad.com> (message from Tim Bass on Sat, 4 Nov 1995 17:38:45 -0500 (EST)) Subject: Re: New book on routing Tim (et al.), The intent for IPv6 is to extend IDRP to carry IPv6 prefixes. The AS number is history and the "domain identifier" ;-) is simply an IPv6 address taken from the prefix assigned to the domain. [Yes, this does add a restriction that you have an allocated address before you inject an IPv6 route. We didn't think that this was too much of a restriction. ;-)] This obviates the need to expand the AS number space, which would quickly become critical. Note that we could add a convention to trivially embed IPv4 AS numbers in the compatibility space of the IPv6 address, giving you bidrectional portability with BGP4. I was under the impression that IPv6 was getting close to the finish line Interesting. Guess it depends on your idea of the finish line. My idea is when we can turn off the IPv4 hosts. It's a ways out... ;-) Further discussion of IDRP in particular should be done in the BGP WG. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15535; 4 Nov 95 21:41 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ab15531; 4 Nov 95 21:41 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa20920; 4 Nov 95 21:41 EST Received: from dune.silkroad.com (dune.silkroad.com [165.209.1.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id NAA13404 for ; Sun, 5 Nov 1995 13:13:03 +1100 Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id VAA00494; Sat, 4 Nov 1995 21:09:29 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Bass Message-Id: <199511050209.VAA00494@dune.silkroad.com> Subject: Re: New book on routing To: Tony Li Date: Sat, 4 Nov 1995 21:09:29 -0500 (EST) Cc: sob@newdev.harvard.edu, HANK@taunivm.tau.ac.il, cidrd@iepg.org In-Reply-To: <199511050122.RAA02081@greatdane.cisco.com> from "Tony Li" at Nov 4, 95 05:22:34 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3154 Tony> > The intent for IPv6 is to extend IDRP to carry IPv6 prefixes. The AS > number is history and the "domain identifier" ;-) is simply an IPv6 Look's like, as usual I have some cat'in up do on IDRP.... I know that IDRP is planned to eventually replace the BGP development track, at least that is how the textbook reads. But, if I can step in dangerous waters, is it safe to assume that the IPv6 header is being designed to incorporate *only* currently advocated routing pardigms ? > > Interesting. Guess it depends on your idea of the finish line. My > idea is when we can turn off the IPv4 hosts. It's a ways out... ;-) > > Further discussion of IDRP in particular should be done in the BGP WG. Thanks. My question is this.... Supposed some consulting engineer had $$$ in the bank, some time and all his bills paid and wanted to develop a super-netting paradigm (perhaps differnet than IDRP), less complex than NIMROD or IDPR [ generic note: IDPR and IDRP are not the same protocols :-)] that used prefixes in the same manner as the AS systems concept *but* was not a derivative of the BGP development track for super-netting and simplified policy routing. Since the idea of using 'AS style' prefixes might be (or is) considered a generic IP concept and not necessarily a BGP concept, is it appropriate to discuss IPv6 header fields in a BGP WG? Or? (please excuse my ignorance on IDRP) does IPv6 headers have *generic* fields that can be used to super-net ip address space in a paradigm different than the current development tracks? It seems, on the surface that the 'final version' of the IPv6 header should be flexible enough that numerous inter-domain routing paradigms (there is that word again ;-) would be possible. This is the reason I am trying to tread lightly in the CIDR WG on this question. I am not sure if CIDR or the BGP working group or the IPNG WG is the place to hammer this out. In an private note, it was implied that to put these prefixes in the IP header a routing protocol that required these fields in the IPv6 header would need to be in the standards track. From this, I inferred that there is currently no IPv6 header fields that exist for supernetting IP address space. This assumption, perhaps wrong, leads to another assumption that the only valid future inter-domain routing protocol on the board are derivates of the IDRP development track which in turn is a derivative of the BGP development track. Is this correct? Thanks, Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+   Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11469; 8 Nov 95 9:47 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09942; 8 Nov 95 9:47 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11450; 8 Nov 95 9:47 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10970; 8 Nov 95 9:27 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: cidrd@iepg.org Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-cidrd-addr-ownership-04.txt Date: Wed, 08 Nov 95 09:27:03 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9511080927.aa10970@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CIDR Deployment Working Group of the IETF. Title : Implications of Various Address Allocation Policies for Internet Routing Author(s) : Y. Rekhter, T. Li Filename : draft-ietf-cidrd-addr-ownership-04.txt Pages : 13 Date : 11/07/1995 IP unicast address allocation and management are essential operational functions for the Public Internet. The exact policies for IP unicast address allocation and management continue to be the subject of many discussions. Such discussions cannot be pursued in a vacuum - the participants must understand the technical issues and implications associated with various address allocation and management policies. The purpose of this document is to articulate certain relevant fundamental technical issues that must be considered in formulating unicast address allocation and management policies for the Public Internet. The major focus of this document is on two possible policies, "address ownership" and "address lending," and the technical implications of these policies for the Public Internet. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cidrd-addr-ownership-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-cidrd-addr-ownership-04.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-cidrd-addr-ownership-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951107102213.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-cidrd-addr-ownership-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cidrd-addr-ownership-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951107102213.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07000; 12 Nov 95 3:11 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06996; 12 Nov 95 3:11 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa04228; 12 Nov 95 3:11 EST Received: from VM.TAU.AC.IL (taunivm.tau.ac.il [132.66.32.4]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id RAA15377 for ; Sun, 12 Nov 1995 17:46:41 +1100 Message-Id: <199511120646.RAA15377@nico.aarnet.edu.au> Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 7575; Sun, 12 Nov 95 08:45:11 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 0053; Sun, 12 Nov 1995 08:45:10 +0200 Date: Sun, 12 Nov 95 08:44:13 IST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hank Nussbacher Subject: Draft version 4 of CIDR FAQ To: cidrd@iepg.org MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Plz discuss updates/changes here: ------------------------------------------------------------------------ The CIDR FAQ DRAFT Version 4 DRAFT 12 November 1995 ------------------------------------------------------------------------ The following document is a collection of Frequently Asked Questions about CIDR. This document is not meant to be a networking/routing guide and tutorial. Where appropriate pointers to other documents of a more general nature have been mentioned. Updates from a previous version are marked with a '|' in column 1. If you have any questions you would like added, please send them to the editor mentioned below: Hank Nussbacher (Tel Aviv University and IBM Israel) hank@vm.tau.ac.il or hank@ibm.net.il If you would like to "discuss" items from this FAQ please send your mail to cidrd@iepg.org This FAQ is being distributed to the following groups and lists: alt.internet.services alt.internet.access.wanted nanog@merit.edu inet-access@earth.com iap@vma.cc.nd.edu local-ir@ripe.net cidrd@iepg.org To retrieve the most up-to-date version of this document: - anonymous FTP: ftp.ibm.net.il/pub/docs/cidr.faq |- http://www.rain.net/faq/cidr.faq.html ------------------------------------------------------------------------ General questions ----------------- 1. What does CIDR stand for? CIDR stands for Classless Inter-Domain Routing and is documented in RFC1517/1518/1519/1520. CIDR is an effective method to stem the tide of IP address allocation as well as routing table overflow. Without CIDR having been implemented in 1994 & 1995, the Internet would not be functioning today. Basically, CIDR eliminates the concept of class A, B, and C networks and replaces this with a generalized "IP prefix". CIDR can be used to perform route aggregation in which a single route can cover the address space of several "old-style" network numbers and thus replace a lot of old routes. This lessens the local administrative burden of updating external routing, saves routing table space in all backbone routers and reduces route flapping (rapid changes in routes), and thus CPU load, in all backbone routers. CIDR will also allow delegation of pieces of what use d to be called "network numbers" to customers, and therefore make it possible to utilize the available address space more efficiently. See question #6 below for details on "IP prefix"s. 2. What is an ASN? ASN stands for Autonomous System Number and acts to merge many networks into a logical domain. 3. What is BGP? BGP stands for Border Gateway Protocol and is the de-facto standard for routing between Autonomous Systems in the Internet. All communications between Internet Service Providers (ISP) is handled via BGP4 which supports CIDR. 4. Why should I make the effort and convert my routing to be CIDRized? The routing tables in the Internet have been growing as fast as the Internet and the router technology specifically and computer technology in general has not been able to keep pace. In December 1990 there were 2190 routes and 2 years later there were over 8500 routes. In July 1995 there are now over 29,000 routes, which require approximately 10 MB in a router with a single peer. Routers at interconnection points (or multi-homed hosts doing full routing with many peers) receive these routes from several peers, and need several dozen megabytes of RAM (and the appropriate CPU horsepower) to handle this. A list of those routers that can handle this appears at the end of this question. Routers with 64MB of memory have the capacity for approximately 60,000 routes after which some routes will just have to be left out of the global routing tables, and the more likely ones to be left out are routes covering small pieces of address space. Without the CIDRization work that has gone on for the past 2 years the routing tables would be in excess of 65,000 routes. By CIDRizing you help the Internet reduce the routing overload as well as increasing the liklihood that in the future your routes will be carried by all ISPs. The major benefit of CIDR is to allow for continuous, uninterrupted growth of the Internet. For a significant percentage of sites connected to the Internet the value of the Internet increases with the total number of sites connected to the Internet. Therefore, taking steps needed to allow for continuous uninterrupted growth (like CIDRizing, or renumbering) is beneficial to such sites. The routers today that are available to handle the full routing table are: cisco 7000 w/ 64Mb cisco 4500 w/ 32Mb IBM ENSS and CNSS w/ 64Mb BayNetworks models AN/ASN/BLN/BCN w/ 32Mb 5. Can you give an example of a simple CIDR configuration for a cisco router? The following example creates 2 aggregates and suppresses any more specific addresses that may be contained within those aggregates. The access-list causes only those nets to be distributed as listed, and not any others that may exist in the BGP routing tables. router bgp 64100 no synchronization aggregate-address 172.16.0.0 255.248.0.0 summary-only aggregate-address 192.168.50.0 255.255.255.0 summary-only neighbor 192.168.54.2 remote-as 65000 neighbor 192.168.54.2 distribute-list 12 out default-metric 70 ! access-list 12 permit 192.168.50.0 0.0.0.255 access-list 12 permit 172.16.0.0 0.7.255.255 An alternate method is via network and route statements: router bgp 64100 no synchronization network 172.16.0.0 mask 255.248.0.0 network 192.168.50.0 mask 255.255.255.0 neighbor 192.168.54.2 remote-as 65000 neighbor 192.168.54.2 default-metric 70 ip route 172.16.0.0 255.248.0.0 Null0 254 ip route 192.168.50.0 255.255.255.0 Null0 254 In this case, only those routes explicitly mentioned in "network" statements will be announced with BGP. For these routes to be announced, there has to be a corresponding route in the IP forwarding table, thus the need to create the static routes. The static routes will also serve as "pull-ups" for the route advertisements and thus prevent route flapping: these routes will always be announced with BGP by this router. Note that as long as more specific routes exist internally in your network, these will be used in preference to the static "less specific" route entries (longest prefix matching is being used). A good rule to follow is to never redistribute IGP learnt routes directly into BGP, but to rather use network or aggregate-address statements. And if you must redistribute dynamically learnt IGP routes into BGP, you MUST use filtering. The reasons for this advice are several, some of which are: 1) if your IGP is classful (e.g. RIP or IGRP) you will by default not do any route aggregation 2) if you have an internal stability problem (accidents do happen), this will be reflected as a "route flap" in the whole routing system, globally burning CPU cycles better spent on other things 3) if the IGP -> BGP transition is unrestricted, this can lead to false routing information escaping from your network (especially if you do not fully have administrative control over your IGP) 6. What do all these /16s and /24s mean in my BGP tables? This refers to the number of bits of the network part of the IP address. A former class B may appear as 172.50.0.0/16, which is the same as 256 class C's which can appear as 192.200.0.0/16. A single class C appears as 192.201.1.0/24. These "things" are often called an "IP prefix", which consists of an IP address and a mask length. The mask length specifies the number of leftmost contiguous significant bits in the corresponding IP address. Thus, an IP prefix with a prefix length of 15 (denoted /15) covers the address space of 128k IP addresses, and a /17 covers the address space of 32k IP addresses. Here is a table of the more popular CIDR blocks: # of former CIDR class C block nets ---- ---- /27 1/8 /26 1/4 /25 1/2 /24 1 /23 2 /22 4 /21 8 /20 16 /19 32 /18 64 /17 128 /16 256 = 1 former class B /15 512 /14 1024 /13 2048 In general, advertising a prefix covering less address space than a /24 prefix will probably not get into the global routing tables, and global Internet connectivity is less likely to happen. Note that for you as an administrator of an AS, it is a good idea to announce as few prefixes as possible and to utilize the address space as much as possible. | A more comprehensive table came out in October 1995 as: | | RFC1860: Variable Length Subnet Table For IPv4 7. Do I need to carry the full Internet routing table? When would it be necessary? What routers on the Internet carry full routing tables and how much memory is needed? No you do not need to carry the full Internet routing table. If you are single-homed, meaning you have a single connection to an ISP, then all you need to do is point a default route to the ISP and tell your ISP not to send you the full routing table. If you are multi-homed, you will want to know which nets to route via connection A and which nets to route via connection B. The easiest way to do this is to request a partial routing table from one ISP - with those nets that are closest to them, and default everything else to the other ISP. This way your routing tables need not contain the entire Internet universe but only a small subset. The closer you get to the hub or nexus of the Internet, the larger your routing tables need to be. For example, those connected to public exchange points (like the NAPs, CIX, STIX, LINX, dGIX) in general, carry full routing tables and run without a default route. 8. What is there in the Internet to stop me from making a mistake and announcing via BGP an aggregate that is larger than the nets I am in charge of? In principle there is nothing to stop you. The responsibility falls on both ends of the BGP link - you are responsible to filter what you announce and the receiving end - if it has its act together - filters also what it *thinks* it should be hearing from you so as prevent mistakes on your part. Those sites that do not work with access lists and filters and just readily accept what is sent to them are just waiting for a problem to happen. Filtering can either be done at the IP network level or at the BGP path (BGP orgin AS) level. See question 20 below for details on a tool to assist in filtering. 9. Who has to renumber with CIDR ? Sites that move from one ISP to another, and who had been allocated addresses from their original ISP's CIDR block, in all likelihood will have to return those addresses as part of the move. The reason is to keep the number of prefixes in the global routing system within the limits of current technology. | For further hints and procedures for renumbering, see the PIER | (Procedures for Internet/Enterprise Renumbering) homepage at: | | http://www.isi.edu:80/div7/pier Specific questions ------------------ 10. I have a /16 but have registered parts of it as /24s in the RADB. I now want to CIDRize. The problem is parts of the /16s are missing and are routed via a different ASN. Can you explain how more specific routes override more general ones and will I hurt my routing if I just advertise the /16 and not a bunch of /20s and /21s? There are two aspects to the answer: 1) Real (BGP) world: Given there are several AS's sharing addresses out of a /16 prefix, every AS should advertise exactly those prefixes which it is really originating. However, if there is one AS "originating" a significant majority of this address space, the concerned AS's might agree that this one and only advertises the /16 and all others their more specifics. The more specifics always take precedence over the less specific. 2) Routing registry: The registry DB, of course, should always reflect reality. If in the above example the AS's agree on the "big AS" announcing the /16, the "big AS" should document with the route-object that it's not really originating the whole aggregate by using "hole" attributes (see ripe.181, 5. The Route Object). 11. How can I redistribute our IGP routes (IGRP) so that they become aggregated when sent out via BGP? It is strongly discouraged to redistribute IGPs into BGP, because local IGP configuration errors might easily corrupt routing information of the whole Internet. If, however, you have to do it anyway, you MUST use strict distribute-lists with explicit permits (or route-maps) for redistribution. Here is an example for a Cisco configuration: router bgp 64100 aggregate-address 192.168.0.0 255.255.192.0 summary-only aggregate-address 172.16.0.0 255.254.0.0 summary-only redistribute igrp 64100 route-map origin-AS64100 ! ! or: ! redistribute igrp 64100 ! distribute-list 10 out igrp 64100 ! route-map origin-AS64100 permit 10 match ip address 10 ! access-list 10 permit 192.168.0.0 0.0.63.0 access-list 10 permit 172.16.0.0 access-list 10 permit 172.17.0.0 This example would generate one route 192.168/18 and one route 172.16/15 if any of the contained networks is in the IGP. 12. I am multihomed to three ISPs and can only CIDRize to two of them but to the third I need to still announce specific nets. What damage will this do to my AS? No damage can be done if the non-CIDR peer does not further announce your specifics to the global Internet. If your non-CIDR ISP DOES announce your specifics to the global Internet those specifics will have preference over the less specifics and therefore all traffic to you will get routed through the non-CIDR ISP. 13. I don't want to CIDRize. Can someone do proxy aggregation for me? Proxy aggregation should only be done with great care and should be avoided if you are not single-homed ! If you are single-homed ask your ISP. Others may proxy aggregate over your address range without your consent, and send your traffic over paths/links not of your choosing. Use of Routing Registries may help to identify and correct these problem areas. 14. What routers on the market today do support CIDR (classless routing)? Routers that are capable of handling CIDR are: - all Cisco routers running 10.0 or higher - all Bay Networks routers running 8.01 or higher - 3Com Netbuilder II and Netbuilder Remote Office - Telebit EMPB - Unix w/ BSD/OS 2.0 w/ gated 3.5alpha_11 + radix-fixes - IBM 2210 routers 15. How do I reach other parts of a subnetted old-style network when I have only partial routing information for that same old-style network?" There are actually three ways to solve this particular problem with Cisco's software. Which of them applies will depend on what software version is involved: o Preferred solution: turn on "ip classless" in your routers and use a default route inside your AS. The "ip classless" command prevents the existence of a single "subnet" route from blocking access via the default route to other subnets of the same old-style network. o Workaround for 9.1 or later software where the "ip classless" command is not available: install a "default network route" like this: "ip route 39.0.0.0 255.0.0.0 next-hop" along the axis your default route would normally take. o Workaround for 9.0 or older software: create a "default subnet route": "ip route 39.x.y.0 next-hop" combined with "ip default-network 39.x.y.0", otherwise as the 9.1 fix. Both of the latter solutions rely on static routes, and in the long run these will be impossible to maintain. In some topologies the use of static routes can be a problem (e.g. if you have more than one possible exit point from your AS to choose from). Supplemental information ------------------------ The following information is presented as supplemental information that is related to the CIDRization process. 16. What is the Internet Routing Registry? The IRR is a way for ASN's to publicize their own intended routing policies without having to request a change from a go-between. The RAdb which stands for the Routing Arbiter Data Base, which is part of the IRR, is part of a joint project between Merit and ISI. For full details contact: http://www.ra.net/routing.arbiter/RA/index.html. The Routing Arbiter is a project of the US National Science Foundation. As part of that project, it runs a routing registry database. That database (the RAdb) forms part of the IRR collection of databases. The RIPE database is not part of the RAdb but does participate in the IRR. At present, there are five entities that contribute to the IRR effort and more are expected. Today, all the contributing registries use the RIPE-181 database format. All IRR participants can be contacted via automail handlers that accept batch updates via email. An example of a routing update appears below: password: xxxxxxxx *rt: 138.134.0.0/16 *de: NET-IEC *or: AS378 *mb: AS378-MNT *ch: hank@aristo.tau.ac.il 950724 *so: RIPE The *rt: tag identifies the net and the routing policy is based on *or: tag. An example of a routing policy is presented below: aut-num: AS378 descr: ILAN descr: Israeli Academic and Research Network as-in: from AS1755 100 accept ANY as-in: from AS174 100 accept ANY as-in: from AS3339 100 accept AS3339 as-out: to AS1755 announce AS378 AS3339 as-out: to AS174 announce AS378 AS3339 as-out: to AS3339 announce ANY default: AS174 10 default: AS1755 20 default: AS3339 30 guardian: HANK@vm.biu.ac.il mnt-by: AS378-MNT admin-c: Hank Nussbacher tech-c: Hank Nussbacher changed: hank@vm.tau.ac.il 950627 source: RIPE For further details read over ripe-120.ps, ripe-121.ps and ripe-181.ps (via anonymous ftp from info.ripe.net/ripe/docs). |17. Are there any statistics available as to aggregation in the | Internet? | COUNTS OF RADB PREFIXES BY LENGTH - The number of Route objects | registered in the RADB, with active and withdrawn routes listed | by prefix length. Data from the current week is available from: | | ftp://ftp.ra.net/routing.arbiter/radb/reports/ | counts-by-prefix/Summarize_prefix.current | | Reports from previous weeks are available from: | | ftp://ftp.ra.net/routing.arbiter/radb/reports/ | counts-by-prefix/summarize_prefix.yymmdd | | IRR ROUTES SUMMARIZED BY PREFIX LENGTH WITH AGGREGATION - A | summary of unique prefixes registered in the IRR. Routes are | summarized by the first octet of the network number. If routes | within a prefix can be aggregated, a count is printed for each | prefix length that has a different count after aggregation. Data | from the current week is available from: | | ftp://ftp.ra.net/routing.arbiter/radb/reports/ | IRR_profile/IRR_Profile.current | | Reports from previous weeks are available from: | | ftp://ftp.ra.net/routing.arbiter/radb/reports/ | IRR_profile/IRR_Profile.yymmdd 18. How do I update the registered routing information for my ASN? You need to submit a "route" object update and perhaps an "aut-num" object update (see examples above). Route objects add new nets to your autonomous system (or you can remove nets from your autonomous system) and the Autonomous-system object describes the type of routing you wish to have. 19. Which Routing database takes precedence? RIPE? RADB? MCI? Do I have to update all of them? Each provider is allowed to select the preference order for authentic data. For example, ANS uses the following precedence: ANS, CANET, MCI, RIPE, RADB If there are two routes (with different origins) within one database, the changed date is used as a tiebreaker. Else, only database precedence is used. Thus, if the RADB entry has a more recent changed date than the RIPE, ANS will use the RIPE entry. You should only have to register in one of the IRR component databases. 20. How do I check what is registered in the IRR? The tool to use is whois. A few examples make the command self explanatory: whois -h whois.ra.net 128.228.0.0 whois -h whois.ripe.net as378 whois -h whois.canet.ca 142.77.0.0 21. Is there a tool to automatically create route filters based on IRR information? rlc is a route list compiler which is a subset of nlc/alc that allows the generation of route based filters (cisco access- lists) by extracting the nets belonging to an AS or AS MACRO from a routing database (i.e. Ripe Routing Database). In addition, it supports a limited set of functions to generate AS based filter lists. rlc is fully classless, and hence supports CIDR routes and subnets, as well as host routes. Source: ftp://dxcoms.cern.ch/pub/ripe-routing-wg Author: Jean-Michel Jouanigot, CERN |22. What other tools are available in the CIDR world? | A web version of this information can be located at: | http://www.ra.net/~ra/tools | | ------------------------ | Online Tools and Reports | ------------------------ | | IRRWeb | | This graphical interface into the Internet Routing Registry makes | it possible to use the Web to query the IRR and update RADB AS | objects, Route objects, and Maintainer objects. Users can enter | any value that can be submitted through a whois query, such as an | AS number, network IP address, or maintainer. IRRWeb then displays | the corresponding AS objects, Route objects, or Maintainer objects | from the various registries in the IRR. Authorized maintainers can | edit the objects directly; IRRWeb performs a cursory pre-check and | mails the revised object to auto-dbm@ra.net. The user then | receives e-mail from auto-dbm confirming and displaying the revised | object, or explaining why the object was rejected. | | See http://www.ra.net/cgi-bin/ra/query-radb.pl | | Source code is available at | ftp://ftp.ra.net/routing.arbiter/tools/irrweb.tar.gz | | | Route History Server | | The Route History Server provides a mechanism for tracking | the announce/withdraw history of a given prefix for the last 24 | hours. The History Server peers with the route servers at | each NAP and records all BGP updates in History Server/Route | Server peering session. | | See http://www.ra.net/cgi-bin/ra/rshist.pl | | | ----------------------- | Tools Available for FTP | ----------------------- | | RSd | | The Route Server daemon (RSd) is an enhanced version of | the GateD routing software that provides multiples views of | routing information. | The software provides a mechanism for network service provides | to off-load the computational complexity of routing policy | calculations from their routers. RSd supports configuration and | transparent passing of BGP MEDs. The software also supports | BGP route flap dampening. | | Available at ftp://ftp.ra.net/routing.arbiter/tools/rsd.tar.gz | | | Peval | A policy evaluator that inputs a RIPE-181 policy | expression, performs essential background | calculations such as symbolic evaluations and | expansions, and outputs another RIPE-181 policy | expression that is used by other tools, such as | RTConfig. | | Available as part of the RAToolSet at | ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet | | | RTConfig | A router configuration tool that can be used by | providers to generate router configs directly from | the RADB or other IRR registries. Currently in | production use for the RA Route Servers, ANSNET, and | CA*net, RTConfig is a front-end tool that uses peval | and radbserver transparently to users. | | Available as part of the RAToolSet at | ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet | | | rrc2r/rrmerge | This Cisco-to-RIPE-181 conversion package makes it possible for | users to convert Cisco router configuration files to RIPE-181 | objects that can be submitted to the Internet Routing Registry | (IRR). The Cisco access-list can be converted into an explicit set | of nets embedded in an AS object or represented as a community. | The RADBserver is queried for any missing or previously registered | information. | | Available at | ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet/rrc2r-0.2.tar.gz | | | CiscoBGP | IRR users have long recognized the need for tools that check the | IRR against routes actually propagated in the Internet. CiscoBGP | obtains and analyzes routing information from production Ciscos, | and compares the data with routes in the IRR. The software also | flags prefixes that are reserved by RFC 1597, Address Allocation | for Private Internets. | | Available as part of the MRT software distribution at | http://www.merit.edu/~mrt | | | BGPCheck | BGPCheck obtains and analyzes routing information from BGP4 | peering sessions, and compares the data with routes in the IRR. The | software also flags prefixes that are reserved by | RFC 1597, Address Allocation for Private Internets. | | Available as part of the MRT software distribution at | http://www.merit.edu/~mrt | | | PRtraceroute | The 'prtraceroute' tool is a powerful form of traceroute that | displays the Autonomous Systems that a packet traverses. | PRtraceroute was developed by the Pride project. | | A version of prtraceroute that queries the RADB is available at | ftp://ftp.ra.net/routing.arbiter/pride/prtraceroute-2.0beta2.shar.gz | | | ------------------ | Tool Announcements | ------------------ | PGP-Based Radb Authentication | Follow these steps to take advantage of the new RADB support for | PGP-based digital signatures: | | 1. Register your public key with the Routing Arbiter Service. | 2. Modify your Maintainer object to reflect your use of digital | signatures. | 3. Use PGP to sign your RADB transactions. | | For detailed instructions, see: | http://www.ra.net/routing.arbiter/RA/RADB.tools.docs/pgp.html Contributors: Christian Panigl - Vienna University, Austria Bill Manning - ISI Tony Li - Cisco Systems Havard Eidnes - SINTEF, Norway Yakov Rekhter - Cisco Systems | Craig Labovitz - Merit Network   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23997; 13 Nov 95 17:34 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23989; 13 Nov 95 17:34 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa21419; 13 Nov 95 17:34 EST Received: from venera.isi.edu (venera.isi.edu [128.9.0.32]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id IAA13627 for ; Tue, 14 Nov 1995 08:22:54 +1100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bmanning@isi.edu Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 13 Nov 1995 13:22:48 -0800 Posted-Date: Mon, 13 Nov 1995 13:19:15 -0800 (PST) Message-Id: <199511132119.AA00369@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Mon, 13 Nov 1995 13:19:15 -0800 Subject: Re: Draft version 4 of CIDR FAQ To: Hank Nussbacher Date: Mon, 13 Nov 1995 13:19:15 -0800 (PST) Cc: cidrd@iepg.org In-Reply-To: <199511120646.RAA15377@nico.aarnet.edu.au> from "Hank Nussbacher" at Nov 12, 95 08:44:13 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 216 > | A more comprehensive table came out in October 1995 as: > | > | RFC1860: Variable Length Subnet Table For IPv4 > RFC 1860 is flawed and is being replaced. New RFC number to be announced shortly. --bill   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00433; 13 Nov 95 23:17 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00429; 13 Nov 95 23:17 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa00643; 13 Nov 95 23:17 EST Received: from nic.hq.cic.net (nic.hq.cic.net [198.108.58.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id OAA20339 for ; Tue, 14 Nov 1995 14:05:12 +1100 Received: (from dorian@localhost) by nic.hq.cic.net (8.7.1/8.6.12) id WAA04431; Mon, 13 Nov 1995 22:04:52 -0500 (EST) Date: Mon, 13 Nov 1995 22:04:52 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dorian Kim X-Sender: dorian@nic.hq.cic.net To: Hank Nussbacher cc: cidrd@iepg.org Subject: Re: Draft version 4 of CIDR FAQ In-Reply-To: <199511120646.RAA15377@nico.aarnet.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 12 Nov 1995, Hank Nussbacher wrote: > 5. Can you give an example of a simple CIDR configuration for a > cisco router? > > The following example creates 2 aggregates and suppresses > any more specific addresses that may be contained within > those aggregates. The access-list causes only those nets > to be distributed as listed, and not any others that may > exist in the BGP routing tables. > > router bgp 64100 > no synchronization > aggregate-address 172.16.0.0 255.248.0.0 summary-only > aggregate-address 192.168.50.0 255.255.255.0 summary-only > neighbor 192.168.54.2 remote-as 65000 > neighbor 192.168.54.2 distribute-list 12 out > default-metric 70 > ! > access-list 12 permit 192.168.50.0 0.0.0.255 > access-list 12 permit 172.16.0.0 0.7.255.255 Depending on your particular set up, you could do this also: router bgp 64100 no synchronization aggregate-address 172.16.0.0 255.248.0.0 aggregate-address 192.168.50.0 255.255.255.0 neighbor 192.168.54.2 remote-as 65000 neighbor 192.168.54.2 distribute-list 102 out default-metric 70 ! access-list 102 deny 172.16.0.0 0.0.7.255 255.255.252.0 0.0.3.255 access-list 102 deny 192.168.50.0 0.0.0.255 255.255.255.128 0.0.0.127 -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07243; 14 Nov 95 2:32 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07239; 14 Nov 95 2:32 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa03185; 14 Nov 95 2:32 EST Received: from VM.TAU.AC.IL (taunivm.tau.ac.il [132.66.32.4]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id RAA25452 for ; Tue, 14 Nov 1995 17:39:05 +1100 Message-Id: <199511140639.RAA25452@nico.aarnet.edu.au> Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 6044; Tue, 14 Nov 95 08:37:31 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 6038; Tue, 14 Nov 1995 08:37:31 +0200 Date: Tue, 14 Nov 95 08:37:13 IST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hank Nussbacher Subject: Re: Draft version 4 of CIDR FAQ To: bmanning@isi.edu, Hank Nussbacher cc: cidrd@iepg.org In-Reply-To: Message of Mon, 13 Nov 1995 13:19:15 -0800 (PST) from MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT On Mon, 13 Nov 1995 13:19:15 -0800 (PST) you said: >> | A more comprehensive table came out in October 1995 as: >> | >> | RFC1860: Variable Length Subnet Table For IPv4 >> > > RFC 1860 is flawed and is being replaced. New RFC number to be > announced shortly. > >--bill I put a note in about that until the revised RFC comes out. Hank   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20207; 14 Nov 95 14:25 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20202; 14 Nov 95 14:25 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa14861; 14 Nov 95 14:25 EST Received: from tampico.cso.uiuc.edu (tampico.cso.uiuc.edu [128.174.81.26]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id EAA02472 for ; Wed, 15 Nov 1995 04:38:16 +1100 Received: from [192.17.16.74] (mac-ross.isdn.uiuc.edu [192.17.16.74]) by tampico.cso.uiuc.edu (8.6.12/8.6.11) with SMTP id LAA13649; Tue, 14 Nov 1995 11:37:30 -0600 X-Sender: rrv@tampico.cso.uiuc.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Nov 1995 11:37:31 -0600 To: Dorian Kim , Hank Nussbacher Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ross Veach Subject: Re: Draft version 4 of CIDR FAQ Cc: cidrd@iepg.org See typo correction below... At 9:04 PM 11/13/95, Dorian Kim wrote: >On Sun, 12 Nov 1995, Hank Nussbacher wrote: > >> 5. Can you give an example of a simple CIDR configuration for a >> cisco router? >> >> The following example creates 2 aggregates and suppresses >> any more specific addresses that may be contained within >> those aggregates. The access-list causes only those nets >> to be distributed as listed, and not any others that may >> exist in the BGP routing tables. >> >> router bgp 64100 >> no synchronization >> aggregate-address 172.16.0.0 255.248.0.0 summary-only >> aggregate-address 192.168.50.0 255.255.255.0 summary-only >> neighbor 192.168.54.2 remote-as 65000 >> neighbor 192.168.54.2 distribute-list 12 out >> default-metric 70 >> ! >> access-list 12 permit 192.168.50.0 0.0.0.255 >> access-list 12 permit 172.16.0.0 0.7.255.255 > >Depending on your particular set up, you could do this also: > > router bgp 64100 > no synchronization > aggregate-address 172.16.0.0 255.248.0.0 > aggregate-address 192.168.50.0 255.255.255.0 > neighbor 192.168.54.2 remote-as 65000 > neighbor 192.168.54.2 distribute-list 102 out > default-metric 70 > ! > access-list 102 deny 172.16.0.0 0.0.7.255 255.255.252.0 0.0.3.255 access-list 102 deny 172.16.0.0 0.7.255.255 255.252.0.0 0.3.255.255 > access-list 102 deny 192.168.50.0 0.0.0.255 255.255.255.128 0.0.0.127 >-dorian >______________________________________________________________________________ > Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive > Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 > CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28244; 14 Nov 95 21:38 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa28240; 14 Nov 95 21:38 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa22444; 14 Nov 95 21:38 EST Received: from plaza.aarnet.EDU.AU (plaza.aarnet.edu.au [139.130.23.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id MAA08481 for ; Wed, 15 Nov 1995 12:25:31 +1100 Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by plaza.aarnet.EDU.AU (8.6.8/8.6.5) with ESMTP id MAA21226 for ; Wed, 15 Nov 1995 12:25:29 +1100 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id RAA21748; Tue, 14 Nov 1995 17:24:07 -0800 Date: Tue, 14 Nov 1995 17:24:07 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199511150124.RAA21748@greatdane.cisco.com> To: cidrd@iepg.org Subject: Document hum Folks, For your leisure reading ;-), please grab a copy of draft-ietf-cidrd-addr-ownership-04.txt. You'll note that there have been a significant number of editorial changes made so that it's much more readable. As the wording has changed, it is vital that you actually _read_ it. Please note that if you disagree with the wording, our sole intent in this pass was to fix the grammar and NOT to change the semantic content. Please load your ammunition accordingly. As I'm being optimistic, I would like to kick off the "hum" for this document. Please send mail to tli@cisco.com by 12:00 PST 11/27/95. In your subject line, please put: Cidrd: hum yes to move the document forward, or Cidrd: hum no to not move the document forward. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02615; 14 Nov 95 23:47 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02606; 14 Nov 95 23:47 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa01318; 14 Nov 95 23:47 EST Received: from lovefm.reston.mci.net (lovefm.Reston.mci.net [166.45.2.37]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id NAA09887 for ; Wed, 15 Nov 1995 13:39:27 +1100 Received: from localhost (localhost.mci.net [127.0.0.1]) by lovefm.reston.mci.net (8.6.12/8.6.6) with ESMTP id VAA11145 for ; Tue, 14 Nov 1995 21:37:41 -0500 Message-Id: <199511150237.VAA11145@lovefm.reston.mci.net> To: cidrd@iepg.org Subject: In the spirit of cidrd - report sort of resurrected Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Bates X-Phone: +1 703 715 7521 Date: Tue, 14 Nov 1995 21:37:41 -0500 X-Orig-Sender: tony@mci.net With IETF coming up here's the top 30 breakdown of where (just looking at classful routes) and aggregating (with no holes) at the AS level we can still make significant gain in routing table space. ==Tony. ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 980 526 454 46.3% i*internet AS174 1277 909 368 28.8% Performance Systems International AS568 1184 879 305 25.8% Milnet FIXes--144(W)/145(E) AS3848 404 217 187 46.3% WORLDLINX AS1324 448 273 175 39.1% ANS New York City - DNSS 35 AS97 514 350 164 31.9% JvNCnet AS3602 324 174 150 46.3% Intergrated Network Services Inc. AS560 458 327 131 28.6% BBN Planet, New England Region (N AS1290 286 155 131 45.8% EUnet GB AS813 326 213 113 34.7% UUNET Canada (ASN-UUNETCA-AS1) AS544 395 285 110 27.8% The DataNet IP Service AS4628 171 61 110 64.3% APNIC-AS-BLOCK AS1836 295 199 96 32.5% EUnet/CH Autonomous System AS1257 275 185 90 32.7% SWIPnet Swedish IP Network AS3258 177 92 85 48.0% contrib.net section A AS1691 188 104 84 44.7% Advanced Network and Services (AN AS2386 212 129 83 39.2% INS-AS AS2044 170 87 83 48.8% WORLDNET-AS AS1204 130 52 78 60.0% SUNYNET-ASN-AS AS600 258 186 72 27.9% OARnet AS AS4230 132 61 71 53.8% EMBRATEL-BR AS1930 158 87 71 44.9% RCCN-NET AS262 172 105 67 39.0% JVNC-II-AS AS137 203 136 67 33.0% GARR AS1849 241 178 63 26.1% PIPEX, Public IP EXchange AS1759 169 110 59 34.9% The DataNet IP Service AS271 136 79 57 41.9% BCnet Backbone AS2018 194 137 57 29.4% The research and academic network AS1899 153 96 57 37.3% Fnet, EUnet-France AS786 267 211 56 21.0% The JANET IP Service   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07595; 15 Nov 95 1:59 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07591; 15 Nov 95 1:59 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa03278; 15 Nov 95 1:59 EST Received: from cesium.clock.org (cesium.clock.org [17.255.4.43]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id QAA00533 for ; Wed, 15 Nov 1995 16:44:26 +1100 Received: by cesium.clock.org id <5570>; Tue, 14 Nov 1995 21:44:10 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sean Doran To: Tony.Bates@mci.net, cidrd@iepg.org Subject: Re: In the spirit of cidrd - report sort of resurrected Message-Id: <95Nov14.214410pst.5570@cesium.clock.org> Date: Tue, 14 Nov 1995 21:44:08 -0800 What in the name of heaven has gotten into everyone in Canada??? I am almost at the point of suggesting we throw the entire country (minus those providers who aren't on Tony's list) off the Internet, starting next week, if they don't start withdrawing more-specific prefixes. Sean. (appalled) - -- rank ASnum NetsNow NetsCIDR NetGain % Gain Description 1 AS2493 980 526 454 46.3% i*internet 4 AS3848 404 217 187 46.3% WORLDLINX 10 AS813 326 213 113 34.7% UUNET Canada (ASN-UUNETCA-AS1) AS271 136 79 57 41.9% BCnet Backbone   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08515; 15 Nov 95 3:40 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08511; 15 Nov 95 3:40 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa04714; 15 Nov 95 3:40 EST Received: from VM.TAU.AC.IL (taunivm.tau.ac.il [132.66.32.4]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id SAA02812 for ; Wed, 15 Nov 1995 18:39:04 +1100 Message-Id: <199511150739.SAA02812@nico.aarnet.edu.au> Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 1588; Wed, 15 Nov 95 09:37:37 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 2344; Wed, 15 Nov 1995 09:37:34 +0200 Date: Wed, 15 Nov 95 09:37:13 IST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hank Nussbacher Subject: Routing wars pending? To: cidrd@iepg.org, nanog@merit.edu MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT I would like to bring up the matter of address ownership. Here is the story: ILAN acts as registry of last resort in Israel. It owns and assigns IP addresses in the 192.114-118.0.0 address range. These 5 blocks are owned by ILAN (AS378). Over the years, many IP addresses have been assigned - in the past to individual companies and more lately CIDR blocks to local ISPs. ILAN takes a 50 one time fee to register the IP address for the requestor. Company FOO which has a class C decides to leave their current ISP - D. They move to ISP - N - which has their own CIDR block and does the good thing - forces the company to renumber and then informs ILAN that the company has relinquished the old class C. This allows me to reclaim IP addresses and form blocks of /22 and /21 which previously could not be done. All good up to this point. ISP D says since they paid the 50 registration fee - they now own the class C forever. I tell them that that is not the case and that the address was registered in the name of the company and not in the name of the ISP. They reassign the class C to other customers - at the same time I have reassigned the reallocated class C to some one else. Their upstream service provider - U - says to D: "Please inform me to delete the networks below from your access-list per Ilan request. It is a policy of U to only delete networks per U's customer request and not anyone else. This issues needs to resolved by you and ILAN and once it has been resolved, please let me what networks to delete." Ok so far. I trust D and ILAN will resolve this peacefully. But what about cases where it cannot be resolved peacfully? The routing tables are gonna start growing. ILAN withdrew 190 routes on August 1st when it started announcing 192.114.0.0/16 and 192.115.0.0/16. Now, since D is announcing a more specific (/24) - it turns out that his route supercedes my larger aggregate. How to combat it? I would have to start reannouncing all my specifics so as to counter-override his /24. What were to happen if this ISP picked a chunk of unused IP address space in my blocks, and started advertising it as /24s? His upstream service provider - U - just accepts it and starts routing. We maintain the authoritative source for IP address ownership in whois.ripe.net. We found that the upstream service provider - U - went and added a route object in whois.ra.net for the /24s (there are 2 cases now) - basely solely on the word of ISP D. So now there is a contradiction between the two databases. Now if D were to start advertising many unallocated /24s, I would be in a big problem and have to restart announcing my specifics. What are people doing in this area today? Are we going to start seeing routing wars? Thanks, Hank Nussbacher Israel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08921; 15 Nov 95 4:22 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08917; 15 Nov 95 4:22 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa05267; 15 Nov 95 4:21 EST Received: from teckla.apnic.net ([192.41.197.18]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id TAA03210 for ; Wed, 15 Nov 1995 19:17:07 +1100 Received: from localhost (davidc@localhost) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id RAA15528; Wed, 15 Nov 1995 17:13:15 +0900 (JST) Message-Id: <199511150813.RAA15528@teckla.apnic.net> X-Authentication-Warning: teckla.apnic.net: Host davidc@localhost didn't use HELO protocol To: Tony Bates cc: cidrd@iepg.org, davidc@teckla.apnic.net Subject: Re: In the spirit of cidrd - report sort of resurrected In-reply-to: Your message of "Tue, 14 Nov 1995 21:37:41 EST." <199511150237.VAA11145@lovefm.reston.mci.net> Date: Wed, 15 Nov 1995 17:13:15 +0900 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "David R. Conrad" >AS4628 171 61 110 64.3% APNIC-AS-BLOCK This is actually: aut-num: AS4628 descr: Pacific Internet Pte Ltd descr: Singapore admin-c: WH1-SG tech-c: WH1-SG notify: stbu@pacific.net.sg mnt-by: MAINT-PIPL changed: hoou@pacific.net.sg 950912 source: APNIC person: Wong Kok Hoou address: Pacific Internet Pte Ltd address: 89 Science Park Drive address: #04-09/12 The Rutherford address: Singapore 118261 phone: +65-772-6524 fax-no: +65-773-6812 e-mail: hoou@technet.sg nic-hdl: WH1-SG notify: dbmon@apnic.net changed: stbu@technet.sg 951017 source: APNIC (what used to be Singapore Technet, connected through JvNCNet). Regards, -drc   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08931; 15 Nov 95 4:22 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08927; 15 Nov 95 4:22 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa05277; 15 Nov 95 4:22 EST Received: from chops.icp.net (chops.icp.net [199.0.55.71]) by nico.aarnet.edu.au (8.6.10/8.6.10) with ESMTP id TAA03123 for ; Wed, 15 Nov 1995 19:09:45 +1100 Received: by chops.icp.net id <20701>; Wed, 15 Nov 1995 03:09:26 -0000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sean Doran To: cidrd@iepg.org, HANK@taunivm.tau.ac.il, nanog@merit.edu Subject: Re: Routing wars pending? Message-Id: <95Nov15.030926-0000_est.20701+1@chops.icp.net> Date: Wed, 15 Nov 1995 03:09:15 -0000 Hm, routing wars. Fun stuff. Expect much heat on this shortly... :( Essentially, the point-of-appeal would probably be the IEPG or NANOG mailing lists, and who would get believed would probably get worked out after some protracted flameage, consultations with lawyers, and arguments about how routing registry technologies will save the planet from routing wars, pollution, and too-strong coffee. My own personal advice wrt people who are thinking of using others' address space without permission is pretty simple: don't do it, you'll lose. Sean.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09468; 15 Nov 95 5:20 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09464; 15 Nov 95 5:20 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa06004; 15 Nov 95 5:20 EST Received: from bugsy.aa.ans.net (bugsy.aa.ans.net [198.83.21.9]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id TAA03460 for ; Wed, 15 Nov 1995 19:49:18 +1100 Received: (from ljp@localhost) by bugsy.aa.ans.net (8.7.1/8.7.1) id IAA196678; Wed, 15 Nov 1995 08:49:07 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Larry J. Plato" Message-Id: <199511150849.IAA196678@bugsy.aa.ans.net> Subject: Re: Routing wars pending? To: Sean Doran Date: Wed, 15 Nov 1995 08:49:07 +0000 (UTC) Cc: cidrd@iepg.org, nanog@merit.edu In-Reply-To: <95Nov15.030926-0000_est.20701+1@chops.icp.net> from "Sean Doran" at Nov 15, 95 03:09:15 am X-Mailer: ELM [version 2.4 PL24 ME6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > and arguments about how routing registry technologies > will save the planet from routing wars, pollution, and too-strong coffee. > With all due respect Sean, the world does not need to be saved from too-strong coffee :) Larry Plato   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11984; 15 Nov 95 8:45 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11980; 15 Nov 95 8:45 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa08834; 15 Nov 95 8:44 EST Received: from nezu.wide.ad.jp (kasoon-fddi.nc.u-tokyo.ac.jp [130.69.250.1]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id WAA05061 for ; Wed, 15 Nov 1995 22:54:13 +1100 Received: from localhost by nezu.wide.ad.jp (8.6.12+2.5Wb7/2.8Wb) id UAA00852; Wed, 15 Nov 1995 20:50:39 +0900 Message-Id: <199511151150.UAA00852@nezu.wide.ad.jp> To: HANK@taunivm.tau.ac.il Cc: cidrd@iepg.org, nanog@merit.edu Subject: Re: Routing wars pending? In-Reply-To: Your message of "Wed, 15 Nov 95 09:37:13 IST" References: <199511150739.SAA02812@nico.aarnet.edu.au> X-Mailer: Mew version 1.00.4 on Emacs 18.59.2, Mule 1.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Wed, 15 Nov 1995 20:50:38 +0900 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Akira Kato At the moment, JPNIC -- the Japanese country NIC -- charges 20,000 yen (about $200) for one-time transaction fee to register the IP address for the requestor. JPNIC delegates address blocks to Japanese NSPs, and the address assignment from the delegated space by a NSP is charged 10,000 yen (about $100). This discount is intended to cover NSP's cost to talk with not-well-knowledged-clients and cost to submit their request form in emails. JPNIC does not monitor how much NSPs actually charges their clients. When a client changes its NSP, JPNIC does not currently charge the one-time registeration fee to the client unless the new address space is not larger than before. This is because these change requests are usually submitted in emails and JPNIC people do not have to talk the requester nor have to create a form from snail-mailed or faxed applications. -- Akira Kato, WIDE Project   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab14172; 15 Nov 95 9:58 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14168; 15 Nov 95 9:58 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa10463; 15 Nov 95 9:58 EST Received: from venera.isi.edu (venera.isi.edu [128.9.0.32]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id AAA06367 for ; Thu, 16 Nov 1995 00:51:30 +1100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bmanning@isi.edu Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 15 Nov 1995 05:51:04 -0800 Posted-Date: Wed, 15 Nov 1995 05:47:30 -0800 (PST) Message-Id: <199511151347.AA02742@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 15 Nov 1995 05:47:30 -0800 Subject: Re: In the spirit of cidrd - report sort of resurrected To: Sean Doran Date: Wed, 15 Nov 1995 05:47:30 -0800 (PST) Cc: Tony.Bates@mci.net, cidrd@iepg.org In-Reply-To: <95Nov14.214410pst.5570@cesium.clock.org> from "Sean Doran" at Nov 14, 95 09:44:08 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 442 > > I am almost at the point of suggesting we throw the entire > country (minus those providers who aren't on Tony's list) > off the Internet, starting next week, if they don't > start withdrawing more-specific prefixes. > > Sean. (appalled) We? What do you mean -we-? I am sure that you can choose to do what you want on your particular pieces of infrastructure, but it might be a bit presumptious to speak for others.... -- --bill   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14192; 15 Nov 95 9:59 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14188; 15 Nov 95 9:59 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa10521; 15 Nov 95 9:59 EST Received: from galaxy (galaxy.net.edu.cn [202.112.0.36]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id AAA06423 for ; Thu, 16 Nov 1995 00:58:59 +1100 Received: from noc5 (noc5.net.edu.cn) by galaxy (5.x/SMI-SVR4) id AA17118; Wed, 15 Nov 1995 20:56:43 +0800 Received: by noc5 (5.x/SMI-SVR4) id AA18932; Wed, 15 Nov 1995 21:58:45 +0800 Date: Wed, 15 Nov 1995 21:58:45 +0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Yang Jiahai Message-Id: <9511151358.AA18932@noc5> To: cidrd@iepg.org Subject: Subscribe I'd like to join the CIDR group. Thanks.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15583; 15 Nov 95 10:56 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15577; 15 Nov 95 10:56 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa11854; 15 Nov 95 10:56 EST Received: from dune.silkroad.com (dune.silkroad.com [165.209.1.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id BAA06824 for ; Thu, 16 Nov 1995 01:54:03 +1100 Received: (from nanog@localhost) by dune.silkroad.com (8.6.12/8.6.9) id JAA02476; Wed, 15 Nov 1995 09:50:38 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Bass (@NANOG-LIST) Message-Id: <199511151450.JAA02476@dune.silkroad.com> Subject: Re: Routing wars pending? To: Hank Nussbacher Date: Wed, 15 Nov 1995 09:50:37 -0500 (EST) Cc: cidrd@iepg.org, nanog@merit.edu In-Reply-To: <199511150739.CAA23462@merit.edu> from "Hank Nussbacher" at Nov 15, 95 09:37:13 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4095 Hank expresses concern: > > What are people doing in this area today? Are we going to start > seeing routing wars? > Hank, In the practical spirit of your question..... I distinctly remember in 1993, preCIDR deployment, when the question was asked around the table at a major corporation (.... not a net discussion, an old-fashioned, face-to-face, meeting :-) We were brainstorming future implementations of CIDR. I had been in the early hot seat as big corps came onto the capital-I Internet, vis-a-vis marketing types having a difficult choice (i.e. their potential big $$ client was using unregistered address space) of renumbering an entire enterprise or losing the account. I held fast, doing the 'right thing', and was very unpopular to the marketing gurus as I held ground stating *renumber* or take your business elsewhere. Luckily, management supported our engineering decisions. Then, in parallel, CIDR was hailed as the 'way to help save B space deletion problems'. At the time, very few had a crystal ball and believed the use of address space would explode to it's post WWW rate. (some did, is the amazing thing!) I have stated this innumerable times, and by saying so put myself in a very unpopular position with certain Internet groups; at the time we consided CIRD blocks to be *portable*. "After all", we stated, "the address space does *not* belong to the provider of connectivity". We also, as a major player at the time, had the unwritten policy " portability of the customer address space, so they could easily move to another provider, was a number one priority". We understood that this opened the door for punching zillions of holes in CIRD, but after all, CIRD was only to be an *interim solution* for a few years for B space depletion. IPv6 would take care of that. Like most people, I moved on to greener, more profitable career pastures and was very surprised to learn that our vision of "completely portable" CIDR address space have been overshadowed by the success of CIDR in another problem area that only those with keen insight at the time could predict, routing table explosion. It was very suprising to me to learn that fate had changed the course of history and aggregation was now the accepted practice for solving most I problems and was not an *interium* or temporary fix, but was to be a core Internet solution. Technically, the aggregation advocates were correct. Socially and politically, aggregation on a global cooperative scale has problems. Historically, when society has been forced into a solution that the general population finds unacceptable, those decisions come back to haunt and trouble us. This is causality, and causality always holds true, IMO. This does not mean that aggregation is not a good thing, it certainly has proven to be the saving technology of the Internet. On the other hand, there are future social and political implementations of global aggregation that are negative. We have discussed these issues and roasted the 'core ideas' repeatedly and my body is scared from raging fires. Cause and effect. No matter what we hope, pray, or design.... it is impossible to design, hope or pray causality out of the event stream. Even the best laid plans of both 'mice and men' ride the big causal ferris wheel. Now, let's see, where are my winterized, flame proof, long johns? After this email, I'm sure to need numerous layers :-) ;-) Regards, Tim +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19715; 15 Nov 95 13:32 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19708; 15 Nov 95 13:32 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa15506; 15 Nov 95 13:32 EST Received: from dixon.DeLong.SJ.CA.US (NS.DELONG.SJ.CA.US [192.159.10.1]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id EAA08229 for ; Thu, 16 Nov 1995 04:22:38 +1100 Received: by dixon.DeLong.SJ.CA.US (8.6.12/SMI-4.1) id JAA05079; Wed, 15 Nov 1995 09:25:52 -0800 Date: Wed, 15 Nov 1995 09:25:52 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Owen DeLong Message-Id: <199511151725.JAA05079@dixon.DeLong.SJ.CA.US> To: cidrd@iepg.org, HANK@taunivm.tau.ac.il, nanog@merit.edu, smd@icp.net Subject: Re: Routing wars pending? > Hm, routing wars. Fun stuff. Expect much heat on this shortly... :( > > Essentially, the point-of-appeal would probably be the IEPG > or NANOG mailing lists, and who would get believed would probably > get worked out after some protracted flameage, consultations with > lawyers, and arguments about how routing registry technologies > will save the planet from routing wars, pollution, and too-strong coffee. > > My own personal advice wrt people who are thinking of using > others' address space without permission is pretty simple: > don't do it, you'll lose. > > Sean. > Ah, but Sean, you missed the essential element of the previous post. Like so many other situations in the middle-east, you have two different factions, both of whom feel that they have legitimate title to the address space in question. Neither of them feels that it belongs to the other. Hence the conflict. The question boils down to who really does own the address space, and frankly, the fact that money changed hands causes me to lean more towads the person who paid. Owen   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21099; 15 Nov 95 15:01 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21094; 15 Nov 95 15:00 EST Received: from [128.250.22.5] by CNRI.Reston.VA.US id aa17456; 15 Nov 95 15:00 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA05370; Thu, 16 Nov 1995 06:48:13 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA05352; Thu, 16 Nov 1995 06:40:37 +1100 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11627; Thu, 16 Nov 1995 06:40:32 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10864; Wed, 15 Nov 95 14:40:03 -0500 Date: Wed, 15 Nov 95 14:40:03 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Noel Chiappa Message-Id: <9511151940.AA10864@ginger.lcs.mit.edu> To: HANK@taunivm.tau.ac.il, nanog@dune.silkroad.com Subject: Re: Routing wars pending? Cc: big-internet@munnari.oz.au, cidrd@iepg.org, jnc@ginger.lcs.mit.edu, nanog@merit.edu Precedence: bulk From: Tim Bass Then, in parallel, CIDR was hailed as the 'way to help save B space [depletion] problems'. ... very surprised to learn that our vision of "completely portable" CIDR address space have been overshadowed by the success of CIDR in another problem area that only those with keen insight at the time could predict, routing table explosion. You keep saying this, but it is *NOT TRUE*. You didn't need "keen insight" to know it was coming, you only needed to be able to *read*, viz (from "Supernetting: an Address Assignment and Aggregation Strategy" RFC-1338, June 1992): As the Internet has evolved and grown over in recent years, it has become painfully evident that it is soon to face several serious scaling problems. These include: ... 2. Growth of routing tables in Internet routers beyond the ability of current software (and people) to effectively manage. ... It has become clear that the first two of these problems are likely to become critical within the next one to three years. This memo attempts to deal with these problems by proposing a mechanism ... So, the routing table problem was well known to be coming at the time that CIDR was under discussion, and the effects of CIDR on address allocation were pointed out in *great* detail in a discussion on the *main* IETF list (look in the archives for the thread "Re: Vote NO on R-L-G IP Address Allocation proposal", and in particular my message of "Sat Oct 31 19:26:04 1992", the infamous "fnortz" message, which pointed out in some detail why renumbering was inevitable). So, if anyone who are around then missed it, they have only themselves to blame. I am damned tired of people rewriting history. Please cease and desist before I become extremely upset. after all, CIRD was only to be an *interim solution* for a few years for B space depletion. IPv6 would take care of that. ... aggregation was now the accepted practice for solving most I problems and was not an *interium* or temporary fix, but was to be a core Internet solution. There is a certain amount of truth to this. CIDR did assume that some "better" fix was coming as part of IPng (and let's not forget, the CIDR debate predated the IPv6 debate - SIP only started to be discussed late that summer). However, as is now I hope obvious to everyone, it's impossible to have a single namespace which is both i) used directly for routing, and ii) identifies hosts directly. To get rid of "renumbering", the Internet needed to split "addresses" as host-identifiers from "addresses" as routing-names, and map one into another. No matter how hard I and some others argued for doing this, though, people didn't want to take that "radical" step of two namespaces. Everyone's moaning now about the painful consequences? Tough. (I take great delight in the fact that one of the principal opponents of splitting off the host-identification function is also one of the people most upset at renumbering. I expect by now, with hindsight to help his understanding along, the irony will have dawned on him.) Technically, the aggregation advocates were correct. Socially and politically, aggregation on a global cooperative scale has problems. Which is why we need *two* namespaces: one for the routing to do what mathematics forces it to, and one for the humans to be able to dork with. there are future social and political implementations of global aggregation that are negative. There are some very painful routing consequences, even with two separate name-spaces (e.g. things like inbound traffic bias), but these are technical problems which will only admit of technical fixes. We have to investigate various possible technical solutions, and weigh the costs of them against the benefit of doing it the way we'd like, but that debate has to be a purely technical one, *not* a policy debate. Now, let's see, where are my winterized, flame proof, long johns? After this email, I'm sure to need numerous layers :-) ;-) Hah! When I get *really* grumpy, you better have something better than miserable protective clothing! Try a bunker reinforced to +125 PSI blast overpressure! :-) Noel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22173; 15 Nov 95 16:03 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22169; 15 Nov 95 16:03 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa18615; 15 Nov 95 16:03 EST Received: from chops.icp.net (chops.icp.net [199.0.55.71]) by nico.aarnet.edu.au (8.6.10/8.6.10) with ESMTP id HAA09606 for ; Thu, 16 Nov 1995 07:17:04 +1100 Received: by chops.icp.net id <20701>; Wed, 15 Nov 1995 15:17:00 -0000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sean Doran To: cidrd@iepg.org, HANK@taunivm.tau.ac.il, nanog@merit.edu, owen@delong.sj.ca.us, smd@icp.net Subject: Re: Routing wars pending? Message-Id: <95Nov15.151700-0000_est.20701+5@chops.icp.net> Date: Wed, 15 Nov 1995 15:16:59 -0000 Owen - I direct you to Yakov Rekhter's various drafts and commentaries that underline the fact that address ownership is irrelevant. Prefixes are simply strings of bits. What's important is the routing system. The fact that you are registered in registry X as being the "owner" of prefix Y is completely irrelevant if pretty much the entire Internet is going to route X towards Z. Now, fortunately, people are working on systems which will keep histories of route announcements and withdrawals so we can see which direction any given prefix was routed towards on a more historical basis. This may be as helpful in solving disputes as it will be in debugging routing. Sean.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23768; 15 Nov 95 16:51 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ab23764; 15 Nov 95 16:51 EST Received: from [128.250.22.5] by CNRI.Reston.VA.US id aa19608; 15 Nov 95 16:51 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA05579; Thu, 16 Nov 1995 08:46:24 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA05530; Thu, 16 Nov 1995 08:35:54 +1100 Received: from faline.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21100; Thu, 16 Nov 1995 08:34:46 +1100 (from little@faline.bellcore.com) Received: from faline (localhost [127.0.0.1]) by faline.bellcore.com (8.6.9/8.6.10) with ESMTP id QAA22225; Wed, 15 Nov 1995 16:33:41 -0500 Message-Id: <199511152133.QAA22225@faline.bellcore.com> To: Noel Chiappa Cc: HANK@taunivm.tau.ac.il, nanog@dune.silkroad.com, big-internet@munnari.oz.au, cidrd@iepg.org, nanog@merit.edu Subject: Re: Routing wars pending? In-Reply-To: Your message of "Wed, 15 Nov 1995 14:40:03 EST." <9511151940.AA10864@ginger.lcs.mit.edu> Date: Wed, 15 Nov 1995 16:33:40 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Little Precedence: bulk In regards to: >(Tim Bass) > Technically, the aggregation advocates were correct. Socially and > politically, aggregation on a global cooperative scale has problems. >(Noel) >Which is why we need *two* namespaces: one for the routing to do what >mathematics forces it to, and one for the humans to be able to dork with. This idea has been around *long* enough. When do we separate the name spaces? How about along with the IPng transition? -Mike   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24133; 15 Nov 95 17:06 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa24129; 15 Nov 95 17:06 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa19986; 15 Nov 95 17:06 EST Received: from cicese.cicese.mx (cicese.cicese.mx [158.97.1.33]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id IAA10030 for ; Thu, 16 Nov 1995 08:14:08 +1100 Received: from knuth-gw.cicese.mx (knuth.cicese.mx) by cicese.cicese.mx (4.1/SMI-4.1) id AA28019; Wed, 15 Nov 95 13:11:23 PST Date: Wed, 15 Nov 95 13:11:23 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Raymundo Vega Aguilar Message-Id: <9511152111.AA28019@cicese.cicese.mx> To: cidrd@iepg.org Subject: Re: Routing wars pending? The answer to this problem is not simple, and that depends on what are you paying,is it the ip address or the paperwork needed to assign it to your network? I think that people is paying only the paperwork, let me give you a good example, is like the addres of your house, if the post office charges with a specific amount of money to link your address (the one of the house where you live) with your person, it doesn't mean that the link is forever, once you move somewhere else you have to repeat the process at the postal office. Raymundo.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25345; 15 Nov 95 18:11 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25340; 15 Nov 95 18:11 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa21404; 15 Nov 95 18:11 EST Received: from munnari.oz.au (munnari.OZ.AU [128.250.1.21]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id JAA10643 for ; Thu, 16 Nov 1995 09:00:28 +1100 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12365; Thu, 16 Nov 1995 09:00:17 +1100 (from kre@munnari.OZ.AU) To: Sean Doran Cc: cidrd@iepg.org, HANK@taunivm.tau.ac.il, nanog@merit.edu, owen@delong.sj.ca.us Subject: Re: Routing wars pending? In-Reply-To: Your message of "Wed, 15 Nov 1995 15:16:59 -0000." <95Nov15.151700-0000_est.20701+5@chops.icp.net> Date: Thu, 16 Nov 1995 08:59:30 +1100 Message-Id: <1979.816472770@munnari.OZ.AU> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Elz Date: Wed, 15 Nov 1995 15:16:59 -0000 From: Sean Doran Message-ID: <95Nov15.151700-0000_est.20701+5@chops.icp.net> What's important is the routing system. This is certainly true. The fact that you are registered in registry X as being the "owner" of prefix Y is completely irrelevant if pretty much the entire Internet is going to route X towards Z. As is this from a practical sense - but we really need to look a little beyond that. If we simply look at the routing system, we find that longest match preference is the way to go, which argues, very strongly that in order to keep routing working, everyone should inject (at least) /24's (no shorter) prefixes, so they won't be overrideden by a longer prefix from elswhere, to be absolutely safe all advertisments should probably be /32's for every host in every organisation, backed up by /31's /30's /29's ... going back as far as needs routing so the longest possible length will get through any prefix length filters that exist. I don't think that is quite what cidrd is attempting to accomplish. If we step beyond letting the routing system be the sole arbiter of what addresses are useful, so people can be encouraged to advertise shorter prefixes, with consequent greater risk of them being overridden, there really needs to be some way that the controllers of routing policy (who filters what) can determine that they're doing the "right thing" when they refuse to accept a longer prefix, but still not longer than any prefix length limits, and route according to a shorter one instead. Or that they should allow the longer prefix to override a shorter one. History of routes may allow some of that to be automated, but that is never going to be sufficient. What's needed is a list of just where routes should be accepted from - which equates pretty much with address owneship, though says nothing about the permanence of that ownership. kre   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25402; 15 Nov 95 18:14 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25398; 15 Nov 95 18:14 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa21459; 15 Nov 95 18:14 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA05682; Thu, 16 Nov 1995 10:06:38 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA05664; Thu, 16 Nov 1995 10:04:07 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19660; Thu, 16 Nov 1995 10:04:03 +1100 (from nanog@dune.silkroad.com) Received: (from nanog@localhost) by dune.silkroad.com (8.6.12/8.6.9) id RAA05851; Wed, 15 Nov 1995 17:59:35 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Bass (@NANOG-LIST) Message-Id: <199511152259.RAA05851@dune.silkroad.com> Subject: Re: Routing wars pending? To: Noel Chiappa Date: Wed, 15 Nov 1995 17:59:35 -0500 (EST) Cc: HANK@taunivm.tau.ac.il, big-internet@munnari.oz.au, cidrd@iepg.org, jnc@ginger.lcs.mit.edu, nanog@merit.edu In-Reply-To: <9511151940.AA10864@ginger.lcs.mit.edu> from "Noel Chiappa" at Nov 15, 95 02:40:03 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2354 Precedence: bulk Noel, With all due respects, no one is rewriting history. In early 1993 I had little time to read IETF threads on the aggregation issue, kind sir. We were working 12-16 hours a day moving big corporations and corporate networks into a position to be a part of the big I. It was the AGS+ --- 7000s were just a dream....... and from our vantage point the future address space problems were the least of my worries. Keeping corporate network managers from getting fired because they could not move packets or had to renumber three class Bs to connect were my issues. Keeping high power marketing experts from going way over your head and doing battle over ordering a client to renumber was a daily event. The historical IETF WGs have their history, as you remind us. But it is only fair to point out that there are other practical perspectives and day-to-day operations that have historical significance. The IETF is not the *only* organization allowed to have an opinion (and I use the word "organization" very loosely). I do not wish to argue with my Noel. I would rather pick a fight with the devil..... at least I would stand a fighting chance :-) The topic, I thought was something like "router wars" and address space issues. I simple point out that it is causal that there will be problems with global aggregation; and the social, political, and economic ramifications may possibly overshadow any technical drafts the IETF stores in it's archives. Please do not send any life 200 mm shells toward this bunker. I am still having trouble finding my asbestos long johns and teflon helmet ;-) I'm not one to question your dominance in the field, only to learn and work toward similar goals. Best Regards, Tim +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25731; 15 Nov 95 18:36 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25727; 15 Nov 95 18:36 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa21855; 15 Nov 95 18:36 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA05753; Thu, 16 Nov 1995 10:27:13 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA05701; Thu, 16 Nov 1995 10:12:39 +1100 Received: from westie.gi.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20065; Thu, 16 Nov 1995 10:12:37 +1100 (from alan@westie.gi.net) Received: from gaijin.mid.net (gaijin.gi.net [198.247.250.28]) by westie.gi.net (8.7.1/8.7.1) with ESMTP id RAA15330; Wed, 15 Nov 1995 17:12:10 -0600 (CST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Hannan Received: by gaijin.mid.net (8.7.1) id RAA00426; Wed, 15 Nov 1995 17:12:07 -0600 (CST) Message-Id: <199511152312.RAA00426@gaijin.mid.net> Subject: Re: Routing wars pending? To: nanog@merit.edu Date: Wed, 15 Nov 1995 17:12:06 -0600 (CST) Cc: jnc@ginger.lcs.mit.edu, HANK@taunivm.tau.ac.il, nanog@dune.silkroad.com, big-internet@munnari.oz.au, cidrd@iepg.org, Mike Little In-Reply-To: <199511152133.QAA22225@faline.bellcore.com> from "Mike Little" at Nov 15, 95 04:33:40 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk Salutations. ] >(Tim Bass) ] > Technically, the aggregation advocates were correct. Socially and ] > politically, aggregation on a global cooperative scale has problems. ] >(Noel) ] >Which is why we need *two* namespaces: one for the routing to do what ] >mathematics forces it to, and one for the humans to be able to dork with. ] (Mike) ] This idea has been around *long* enough. When do we separate the name ] spaces? How about along with the IPng transition? I ask the following question naievely because I don't know how to ask it maturely. What are the correlations and contrasts between our current backbone routing problems (wrt space and # of routes) and the FCC decision several years ago to make 1-800 numbers portable. Is there any correlation? I realize (think) that the FCC ruling was localized to the US, perhaps not..... I ask because I see the a potential scenario when we are forced to play hardball wrt non portability of new CIDR routes. Imagine this... Big corporation leaves us having been allocated /21 of address space. We tell them to get new IP numbers from their provider and backbone smart people make it known they won't propogate routes (you wouldn't, right Sean?). They say get stuffed, and get a congress person to propose a bill that all IP numbers are portable. This bill passes. It could happen. Any thoughts? -alan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25921; 15 Nov 95 19:00 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25917; 15 Nov 95 19:00 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa22195; 15 Nov 95 19:00 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA05799; Thu, 16 Nov 1995 10:46:41 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA05777; Thu, 16 Nov 1995 10:41:07 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22817; Thu, 16 Nov 1995 10:41:03 +1100 (from avg@sprint.net) Received: from titan.sprintlink.net by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10463 Thu, 16 Nov 1995 10:40:59 +1100 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id SAA10459; Wed, 15 Nov 1995 18:37:33 -0500 Date: Wed, 15 Nov 1995 18:37:33 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vadim Antonov Message-Id: <199511152337.SAA10459@titan.sprintlink.net> To: jnc@ginger.lcs.mit.edu, little@faline.bellcore.com Subject: Re: Routing wars pending? Cc: HANK@taunivm.tau.ac.il, big-internet@munnari.oz.au, cidrd@iepg.org, nanog@dune.silkroad.com, nanog@merit.edu Precedence: bulk Silly. We already *do have two namespaces*. One is EIDs in form of FQDNs. They are portable. Another is IPv4 addresses which aren't. How about fixing the real problem -- i.e. making renumbering easy and removing all hardwired addresses from the software? (And, yes, fixing DNS). The magic-cookie EID scheme is nothing more than more complexity to work around the broken implementations. That extra level of indirection is patently useless otherwise. Even funnier, implementation of magic cookie EIDs requires changes in exactly the same pieces of software which need to be changed to repair existing two-level scheme. Note that fixing DNS (and you *have* to do that anyway if you want to use intermediate EIDs) is a lot easier than replacing routers, and does not introduce compatibility problems at the transport level. Sorry, nobody managed to make any reasonable case pro magic-cookie EIDs as yet. The best rationale i've heard was from Noel who said that his "architect's sense" tells him so. Funny thing, a surgeon i know was at loss when i asked him about this function of organism, should be a new discovery in medicine. --vadim In regards to: >(Tim Bass) > Technically, the aggregation advocates were correct. Socially and > politically, aggregation on a global cooperative scale has problems. >(Noel) >Which is why we need *two* namespaces: one for the routing to do what >mathematics forces it to, and one for the humans to be able to dork with. This idea has been around *long* enough. When do we separate the name spaces? How about along with the IPng transition? -Mike   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26157; 15 Nov 95 19:17 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa26153; 15 Nov 95 19:17 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa22507; 15 Nov 95 19:17 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA05836; Thu, 16 Nov 1995 11:06:26 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA05801; Thu, 16 Nov 1995 10:46:45 +1100 Received: from chops.icp.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23933; Thu, 16 Nov 1995 10:46:42 +1100 (from smd@icp.net) Received: by chops.icp.net id <20701>; Wed, 15 Nov 1995 18:46:32 -0000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sean Doran To: alan@gi.net, nanog@merit.edu Subject: Re: Routing wars pending? Cc: big-internet@munnari.oz.au, cidrd@iepg.org, HANK@taunivm.tau.ac.il, jnc@ginger.lcs.mit.edu, little@faline.bellcore.com, nanog@dune.silkroad.com Message-Id: <95Nov15.184632-0000_est.20701+11@chops.icp.net> Date: Wed, 15 Nov 1995 18:46:24 -0000 Precedence: bulk >Any thoughts? Yup, when that happens, the USA ends up being the big loser in the game of global Internet connectivity. Sean.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27301; 15 Nov 95 20:59 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa27297; 15 Nov 95 20:59 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa23926; 15 Nov 95 20:59 EST Received: from nic.hq.cic.net (nic.hq.cic.net [198.108.58.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id MAA14761 for ; Thu, 16 Nov 1995 12:04:05 +1100 Received: (from dorian@localhost) by nic.hq.cic.net (8.7.1/8.6.12) id UAA28560; Wed, 15 Nov 1995 20:04:00 -0500 (EST) Date: Wed, 15 Nov 1995 20:04:00 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dorian Kim X-Sender: dorian@nic.hq.cic.net To: bmanning@isi.edu cc: Sean Doran , Tony.Bates@mci.net, cidrd@iepg.org Subject: Re: In the spirit of cidrd - report sort of resurrected In-Reply-To: <199511151347.AA02742@zed.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 15 Nov 1995 bmanning@ISI.EDU wrote: > > I am almost at the point of suggesting we throw the entire > > country (minus those providers who aren't on Tony's list) > > off the Internet, starting next week, if they don't > > start withdrawing more-specific prefixes. > > We? What do you mean -we-? I am sure that you can choose to > do what you want on your particular pieces of infrastructure, > but it might be a bit presumptious to speak for others.... Bill, perhaps you are being a bit oversensitive? Sean said he's almost at the point of _suggesting_ that. I don't consider that speaking for anyone else. -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06066; 16 Nov 95 0:36 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06062; 16 Nov 95 0:36 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa01781; 16 Nov 95 0:36 EST Received: from wolf.riga.lv (wolf.riga.lv [194.8.12.90]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id PAA18084 for ; Thu, 16 Nov 1995 15:08:17 +1100 Received: from stoat.riga.lv by wolf.riga.lv with SMTP id AA01491 (5.65.kiae-1 for ); Thu, 16 Nov 1995 05:58:35 +0200 Received: from mailbox.riga.lv (stoat.riga.lv) by stoat.riga.lv with SMTP id AA04651 (5.65.kiae-1 for ); Thu, 16 Nov 1995 06:01:12 +0200 Date: Thu, 16 Nov 1995 06:01:10 +0200 Message-Id: <199511160401.AA04651@stoat.riga.lv> X-Sender: mevi@mailbox.riga.lv X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: cidrd@iepg.org Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mhini Subject: information P/se, Which factors i'm supposed to consider in buying : 1.Server 2.nodes 3.hub 4.operation system Netware . Mhini. queny   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10342; 16 Nov 95 8:54 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10338; 16 Nov 95 8:54 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa08451; 16 Nov 95 8:54 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA06861; Fri, 17 Nov 1995 00:46:38 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA06834; Fri, 17 Nov 1995 00:36:45 +1100 Received: from ncc.ripe.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06137; Fri, 17 Nov 1995 00:36:32 +1100 (from dfk@ripe.net) Received: from reif.ripe.net by ncc.ripe.net with SMTP id AA13585 (5.65a/NCC-2.30); Thu, 16 Nov 1995 14:26:23 +0100 Message-Id: <9511161326.AA13585@ncc.ripe.net> To: Alan Hannan Cc: nanog@merit.edu, jnc@ginger.lcs.mit.edu, HANK@taunivm.tau.ac.il, nanog@dune.silkroad.com, big-internet@munnari.oz.au, cidrd@iepg.org, Mike Little Subject: Routing wars pending? In-Reply-To: Your message of Wed, 15 Nov 1995 17:12:06 CST. <199511152312.RAA00426@gaijin.mid.net> References: <199511152312.RAA00426@gaijin.mid.net> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Daniel Karrenberg X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Date: Thu, 16 Nov 1995 14:26:17 +0100 X-Orig-Sender: Daniel.Karrenberg@ripe.net Precedence: bulk > Alan Hannan writes: > > What are the correlations and contrasts between our current > backbone routing problems (wrt space and # of routes) and the FCC > decision several years ago to make 1-800 numbers portable. Correlations are manifold. The most striking contrasts: - Implementation on the 1-800 numbers was straightforward - number space quite small - routing fairly centralised - on the level of the 1-800 address space there is quite static routing, I understand that database updates at that time were done by shipping magtapes - The problem was local to one country and jurisdiction due to the addressing hierarchy > I ask because I see the a potential scenario when we are forced to > play hardball wrt non portability of new CIDR routes. Imagine > this... Big corporation leaves us having been allocated /21 of > address space. We tell them to get new IP numbers from their provider > and backbone smart people make it known they won't propogate > routes (you wouldn't, right Sean?). They say get stuffed, and get > a congress person to propose a bill that all IP numbers are > portable. This bill passes. They also passed a bill once to make PI 3 or some such, didn't they? Daniel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12161; 16 Nov 95 9:58 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12157; 16 Nov 95 9:58 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa09672; 16 Nov 95 9:58 EST Received: from ncc.ripe.net (ncc.ripe.net [193.0.0.129]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id AAA25660 for ; Fri, 17 Nov 1995 00:21:38 +1100 Received: from reif.ripe.net by ncc.ripe.net with SMTP id AA13524 (5.65a/NCC-2.30); Thu, 16 Nov 1995 14:20:27 +0100 Message-Id: <9511161320.AA13524@ncc.ripe.net> To: Robert Elz Cc: Sean Doran , cidrd@iepg.org, HANK@taunivm.tau.ac.il, nanog@merit.edu, owen@delong.sj.ca.us Subject: Routing wars pending? In-Reply-To: Your message of Thu, 16 Nov 1995 08:59:30 +1100. <1979.816472770@munnari.OZ.AU> References: <1979.816472770@munnari.OZ.AU> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Daniel Karrenberg X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Date: Thu, 16 Nov 1995 14:20:25 +0100 X-Orig-Sender: Daniel.Karrenberg@ripe.net > Robert Elz writes: > > What's needed is a list of just where routes should be accepted > from - which equates pretty much with address owneship, though > says nothing about the permanence of that ownership. A routing registry strongly coupled with an assignment registry: The RIPE database. Daniel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16947; 16 Nov 95 13:19 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16943; 16 Nov 95 13:19 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa14295; 16 Nov 95 13:19 EST Received: from overworked.sura.net (overworked.sura.net [128.167.254.217]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id CAA26651 for ; Fri, 17 Nov 1995 02:38:49 +1100 Received: from LOCALHOST.sura.net by overworked.sura.net (4.1/($Id: sendmail.cf,v 1.17 1991/02/11 14:07:23 jmalcolm Exp $)) id AA06206; Thu, 16 Nov 95 10:37:36 EST Message-Id: <9511161537.AA06206@overworked.sura.net> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: ser-rr@ser.bbnplanet.net To: Daniel Karrenberg Cc: cidrd@iepg.org, nanog@merit.edu Subject: Re: Routing wars pending? In-Reply-To: Your message of Thu, 16 Nov 1995 14:20:25 +0100. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Nov 1995 10:37:35 -0500 X-Orig-Sender: nacr@sura.net > > > Robert Elz writes: > > > > What's needed is a list of just where routes should be accepted > > from - which equates pretty much with address owneship, though > > says nothing about the permanence of that ownership. > > A routing registry strongly coupled with an assignment registry: > The RIPE database. > > Daniel Unfortnately, those of us who aren't actual registries can't use the RIPE setup in quite the same fashion. Personally, I'd prefer to just run a RIPE-like RR, rather than running an RR and an RWhois server, or running an RR and sending in SWIPs all the time.... Unfortunately, the Internic doesn't quite seem to see it from my perspective. _k   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18330; 16 Nov 95 14:16 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18326; 16 Nov 95 14:16 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa15580; 16 Nov 95 14:16 EST Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id EAA27320 for ; Fri, 17 Nov 1995 04:09:19 +1100 Received: by rip.psg.com (Smail3.1.29.1 #1) id m0tG7o5-00031WC; Thu, 16 Nov 95 09:09 PST Message-Id: Date: Thu, 16 Nov 95 09:09 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Randy Bush To: cidrd@iepg.org Subject: geographic as opposed to topologic allocation OK. What am I misssing in this picture? Date: Thu, 16 Nov 1995 12:00:05 -0500 From: help@uunet.uu.net (UUNET Customer Liaison) To: randy@psg.com Subject: Re: Re: Help me to ask for classes C (TS065815) Cc: jlmarest@ts.es Reply-to: help@uunet.uu.net Re: Account x Please do not take the (TSXXXXX) information out of the subject header when replying to this problem. We use this number to track specific customer issues. Thank you. > Hi Help, > > It is rumored that one Ralph T. Davis of AlterNet has advised Telefonica > Peru, who plans to hook up via AlterNet, that they should get their address > space from Red Cientifica Peruana, another Peruvian provider which connects > via SprintLink. This is true, since the general practice is to obtain them from the local authorized registering body. IP numbers have been allocated regionally and should be disseminated in the same manner. Based on an agreement between InterNIC, RISK, et al., Class C's should be regionally obtained, or in the case of Telefonica, requested directly from InterNIC. They have the information required to set them up correctly, whereas UUnet does not. The InterNIC accepts direct requests from certain regions, but not ALL regions. > I would have expected AlterNet to allocate non-portable provider space. If we have a customer in India, they get space from India. Japan gets space in Japan. This is regional, not arbitrary. RFC1518 does partially address this ("An Architecture for IP Address Allocation with CIDR") > > In light of CIDR, a dozen current drafts, ... could you please explain this > decision/policy? It kinda scares me to think of AlterNet doing this on a > widespread basis. The policy is not ours, but is the concept of the registering bodies like InterNIC, and appears to have roots in international laws and boundary issues. Thank you, David Costa (for Peter Crafts) UUnet Technical Supprt 1-800-900-0241 help@uunet.uu.net   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19556; 16 Nov 95 15:18 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19552; 16 Nov 95 15:18 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa19571; 16 Nov 95 15:18 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA07308; Fri, 17 Nov 1995 07:07:29 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA07279; Fri, 17 Nov 1995 06:52:11 +1100 Received: from faline.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27723; Fri, 17 Nov 1995 06:52:08 +1100 (from little@faline.bellcore.com) Received: from faline (localhost [127.0.0.1]) by faline.bellcore.com (8.6.9/8.6.10) with ESMTP id OAA09162; Thu, 16 Nov 1995 14:51:50 -0500 Message-Id: <199511161951.OAA09162@faline.bellcore.com> To: Daniel Karrenberg , Alan Hannan Cc: big-internet@munnari.oz.au, cidrd@iepg.org Subject: Re: Routing wars pending? In-Reply-To: Your message of "Thu, 16 Nov 1995 14:26:17 +0100." <9511161326.AA13585@ncc.ripe.net> Date: Thu, 16 Nov 1995 14:51:47 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Little Precedence: bulk (Notes: I've trimed the Cc list assuming all previous originators are on one of the lists anyway, *and* as this topic may be getting little off topic for these mailing lists, I'll try to maintain relevance) > Alan Hannan writes: > > What are the correlations and contrasts between our current > backbone routing problems (wrt space and # of routes) and the FCC > decision several years ago to make 1-800 numbers portable. > Daniel Karrenberg writes: > >Correlations are manifold. > >The most striking contrasts: > <....snip...> Competing economic interests (subscribers and network providers) motivated the FCC decision. Since the changes needed weren't impossible (just hard) the only impact technology considerations really had was on setting the deadline by which it had to be done. The Internet community currently enjoys setting (and missing) its own timetables. On the surface there appears some correlation to the number portability issue. Subscribers wanted to keep their "address" even though they may have changed network providers. When the routing system is routing based on provider, and not subscriber, the "portability problem" can exist. In the 1-800 pre-portability days, 800 numbers were translated on the basis of the network provider who "owned" the number. Be aware that the end point identity in the 1-800 scenario is the 1-800 number. The 800 number itself is translated to another number which is utilized by the network provider(s) for routing purposes. In the Internet environment the end point identity is somewhat muddled, but from a *general* perspective can be considered the domain name. Based on this, there isn't a correlation with the 1-800 portability problem because you can keep your domain name even though you changed network provider (e.g. there is no corresponding problem). However, if (or when) you consider the IP address to be the end point identifier, then the portability problem does exist. Now the focus should be placed on the scope of the portability problem. This is important because in some sense there is always a "portability" issue but not necessarily a "problem". When routing is based on some domain, such as network or provider or mask, then there is a "portability" issue for end points that relocate outside of that domain. Thus, if an end point becomes aligned with another routing domain for one reason or another (i.e. 1-800 example where the user subscribes to another provider, or the IP routing environment wants to re-organize routing domains) there is an impact. This is, of course, only a problem if you don't like the impact. I'll just quickly point out that this impact involves issues such as who absorbs the dynamics of the re-assignment, how they are absorb, and the persistence of the identity (persistence is important for usability). I like the EID approach, but I'll leave that discussion for another message. In regards to Alan's inquiry concerning space and number of routes: As far as I'm aware the 1-800 portability decision (or surrounding issues) did not involve considerations for space, either in terms of address space exhaustion - which is a current issue - or size of translation tables, or for numbers of routes (e.g. no route "explosion"). The 1-800 portability problem was in essence a difficulty in maintaining identity. -Mike   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20183; 16 Nov 95 15:33 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20179; 16 Nov 95 15:33 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa20800; 16 Nov 95 15:33 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA07356; Fri, 17 Nov 1995 07:26:26 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA07327; Fri, 17 Nov 1995 07:14:28 +1100 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19896; Fri, 17 Nov 1995 07:14:22 +1100 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id NAA17464; Thu, 16 Nov 1995 13:26:53 -0800 Date: Thu, 16 Nov 1995 13:26:52 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Michael Dillon X-Sender: michael@okjunc.junction.net To: Daniel Karrenberg Cc: Alan Hannan , nanog@merit.edu, jnc@ginger.lcs.mit.edu, HANK@taunivm.tau.ac.il, nanog@dune.silkroad.com, big-internet@munnari.oz.au, cidrd@iepg.org, Mike Little Subject: Re: Routing wars pending? In-Reply-To: <9511161326.AA13585@ncc.ripe.net> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 16 Nov 1995, Daniel Karrenberg wrote: > They also passed a bill once to make PI 3 or some such, didn't they? In the state where this happened it was passed by their congress but was vetoed in their senate so it never became law. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21578; 16 Nov 95 16:12 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21574; 16 Nov 95 16:12 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa23697; 16 Nov 95 16:12 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA07408; Fri, 17 Nov 1995 08:06:27 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA07379; Fri, 17 Nov 1995 07:54:33 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05583; Fri, 17 Nov 1995 07:54:04 +1100 (from mo@uunet.uu.net) Received: from rodan.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA29797 Fri, 17 Nov 1995 07:38:47 +1100 (from mo@uunet.uu.net) Received: from localhost by rodan.UU.NET with SMTP id QQzqdm06987; Thu, 16 Nov 1995 15:38:24 -0500 Message-Id: To: Mike Little Cc: Daniel Karrenberg , Alan Hannan , big-internet@munnari.oz.au, cidrd@iepg.org Subject: Re: Routing wars pending? In-Reply-To: Your message of "Thu, 16 Nov 1995 14:51:47 EST." <199511161951.OAA09162@faline.bellcore.com> Date: Thu, 16 Nov 1995 15:38:24 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike O'Dell Precedence: bulk 800 portability is NOT a good analogy for IP portability. portability of every phone number between all countries is a much better analogy. it is also much harder. -mo   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23829; 16 Nov 95 17:25 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23825; 16 Nov 95 17:25 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa29140; 16 Nov 95 17:25 EST Received: from Hearts.ACES.COM (Hearts.ACES.COM [192.195.240.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with ESMTP id IAA29030 for ; Fri, 17 Nov 1995 08:18:25 +1100 Received: from ACES.COM by ACES.COM (PMDF V4.3-10 #4107) id <01HXO6W6L0CG00002U@ACES.COM>; Thu, 16 Nov 1995 14:15:49 -0700 (MST) Date: Thu, 16 Nov 1995 14:14:41 -0700 (MST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ehud Gavron Subject: Re: Routing wars pending? In-reply-to: Your message dated "Thu, 16 Nov 1995 13:26:52 -0800 (PST)" To: Michael Dillon Cc: Daniel Karrenberg , Alan Hannan , nanog@merit.edu, jnc@ginger.lcs.mit.edu, HANK@taunivm.tau.ac.il, nanog@dune.silkroad.com, big-internet@munnari.oz.au, cidrd@iepg.org, Mike Little , GAVRON@aces.com Message-id: <01HXPPLND9PE00002U@ACES.COM> Organization: ACES Research Inc. MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT I don't know what this has to do with big-I or cidr but let's just clear the urban legend. It was a small community in Alabama that voted (for their town) to allow PI to equal 3 for the purpose of calculating square footage for property tax. That's it. No grand scheme to defraud Southern schoolkids, no legislation of ip_v !=4, just something to make taxes simple. Ehud >On Thu, 16 Nov 1995, Daniel Karrenberg wrote: >> They also passed a bill once to make PI 3 or some such, didn't they? >In the state where this happened it was passed by their congress but was >vetoed in their senate so it never became law. >Michael Dillon Voice: +1-604-546-8022 >Memra Software Inc. Fax: +1-604-542-4130 >http://www.memra.com E-mail: michael@memra.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24067; 16 Nov 95 17:30 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa24063; 16 Nov 95 17:30 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa29532; 16 Nov 95 17:30 EST Received: from ops.internic.net (ops.internic.net [198.41.0.67]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id IAA29269 for ; Fri, 17 Nov 1995 08:31:42 +1100 Received: (kimh@localhost) by ops.internic.net (8.7.1/InterNIC-RS) id QAA14564; Thu, 16 Nov 1995 16:31:36 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kim Hubbard Message-Id: <199511162131.QAA14564@ops.internic.net> Subject: Re: geographic as opposed to topologic allocation To: Randy Bush Date: Thu, 16 Nov 1995 16:31:33 -0500 (GMT-0500) Cc: cidrd@iepg.org In-Reply-To: from "Randy Bush" at Nov 16, 95 09:09:00 am X-Mailer: ELM [version 2.4 PL24alpha4] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Randy, It's true there are blocks of addresses set aside for various geographical areas, however, if someone in Peru is connecting to UUNET than they should receive address space from UUNET if possible. If they were to request it directly from the InterNIC they would receive it from the block set aside for South/Central America. Kim Hubbard InterNIC Registry > OK. What am I misssing in this picture? > > Date: Thu, 16 Nov 1995 12:00:05 -0500 > From: help@uunet.uu.net (UUNET Customer Liaison) > To: randy@psg.com > Subject: Re: Re: Help me to ask for classes C (TS065815) > Cc: jlmarest@ts.es > Reply-to: help@uunet.uu.net > > Re: Account x > > Please do not take the (TSXXXXX) information out of the subject header > when replying to this problem. We use this number to track specific > customer issues. Thank you. > > > Hi Help, > > > > It is rumored that one Ralph T. Davis of AlterNet has advised Telefonica > > Peru, who plans to hook up via AlterNet, that they should get their address > > space from Red Cientifica Peruana, another Peruvian provider which connects > > via SprintLink. > > This is true, since the general practice is to obtain them from the local > authorized registering body. IP numbers have been allocated regionally and > should be disseminated in the same manner. > > Based on an agreement between InterNIC, RISK, et al., Class C's should be > regionally obtained, or in the case of Telefonica, requested directly from > InterNIC. They have the information required to set them up correctly, > whereas UUnet does not. The InterNIC accepts direct requests from certain > regions, but not ALL regions. > > > I would have expected AlterNet to allocate non-portable provider space. > > If we have a customer in India, they get space from India. Japan gets > space in Japan. This is regional, not arbitrary. RFC1518 does partially > address this ("An Architecture for IP Address Allocation with CIDR") > > > > In light of CIDR, a dozen current drafts, ... could you please explain this > > decision/policy? It kinda scares me to think of AlterNet doing this on a > > widespread basis. > > The policy is not ours, but is the concept of the registering bodies > like InterNIC, and appears to have roots in international laws and > boundary issues. > > Thank you, > > David Costa (for Peter Crafts) > UUnet Technical Supprt > 1-800-900-0241 > help@uunet.uu.net >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24289; 16 Nov 95 17:39 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa24283; 16 Nov 95 17:39 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa00249; 16 Nov 95 17:39 EST Received: from gulfa.kuwait.net (gulfa.kuwait.net [199.173.153.226]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id IAA29389 for ; Fri, 17 Nov 1995 08:44:42 +1100 Received: from jwt.kuwait.net by gulfa.kuwait.net with smtp (Smail3.1.28.1 #9) id m0tGC6H-0002eTC; Fri, 17 Nov 95 00:44 GMT Date: Fri, 17 Nov 1995 00:44:08 +0300 (GMT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "John W. Temples" To: cidrd@iepg.org cc: cidrd@iepg.org Subject: Re: geographic as opposed to topologic allocation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 16 Nov 1995, Randy Bush wrote: > > I would have expected AlterNet to allocate non-portable provider space. > > If we have a customer in India, they get space from India. Japan gets > space in Japan. This is regional, not arbitrary. RFC1518 does partially > address this ("An Architecture for IP Address Allocation with CIDR") We've been told the same thing by Alternet. So now there's another /21 in the routing tables because we had to go to RIPE to get addresses instead of them coming from Alternet. -- John W. Temples, III || Providing the first public access Internet Gulfnet Kuwait || site in the Arabian Gulf region   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24920; 16 Nov 95 18:04 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa24916; 16 Nov 95 18:04 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa02122; 16 Nov 95 18:04 EST Received: from piglet.merit.net (piglet.merit.net [198.108.60.92]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id JAA29770 for ; Fri, 17 Nov 1995 09:05:50 +1100 Received: by piglet.merit.net (Smail3.1.29.1 #1) id m0tGCQ7-00001iC; Thu, 16 Nov 95 17:04 EST Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tom 'moof' Spindler Subject: Re: Routing wars pending? To: Ehud Gavron Date: Thu, 16 Nov 1995 17:04:33 -0500 (EST) Cc: michael@memra.com, Daniel.Karrenberg@ripe.net, alan@gi.net, nanog@merit.edu, jnc@ginger.lcs.mit.edu, HANK@taunivm.tau.ac.il, nanog@dune.silkroad.com, big-internet@munnari.oz.au, cidrd@iepg.org, little@faline.bellcore.com, GAVRON@aces.com In-Reply-To: <01HXPPLND9PE00002U@ACES.COM> from "Ehud Gavron" at Nov 16, 95 02:14:41 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 683 Actually, the (original) explanation is correct. The state was Indiana. Read about it in Petr Beckmann's "History of Pi" if you're interested about it. I believe it has the full story. > It was a small community in Alabama that voted (for their town) to > allow PI to equal 3 for the purpose of calculating square footage > for property tax. > > That's it. No grand scheme to defraud Southern schoolkids, no legislation > of ip_v !=4, just something to make taxes simple. > > >> They also passed a bill once to make PI 3 or some such, didn't they? > > >In the state where this happened it was passed by their congress but was > >vetoed in their senate so it never became law.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25509; 16 Nov 95 18:34 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25505; 16 Nov 95 18:34 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa04259; 16 Nov 95 18:34 EST Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id JAA00381 for ; Fri, 17 Nov 1995 09:37:46 +1100 Received: by rip.psg.com (Smail3.1.29.1 #1) id m0tGCw9-00031GC; Thu, 16 Nov 95 14:37 PST Message-Id: Date: Thu, 16 Nov 95 14:37 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Randy Bush To: Kim Hubbard Cc: cidrd@iepg.org, help@uunet.uu.net Subject: Re: geographic as opposed to topologic allocation References: <199511162131.QAA14564@ops.internic.net> > It's true there are blocks of addresses set aside for various geographical > areas, however, if someone in Peru is connecting to UUNET than they > should receive address space from UUNET if possible. If they were to > request it directly from the InterNIC they would receive it from the block > set aside for South/Central America. Thanks Kim, Quick, before the ISOC or ITU or whomever change all this , how can I communicate this to UUNET staff? Is a statement from the InterNIC of "should receive address space from UUNET if possible," authoritative? draft-hubbard-registry-guidelines-00.txt would seem helpful, but it's just a draft. randy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25954; 16 Nov 95 18:54 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25950; 16 Nov 95 18:54 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa05668; 16 Nov 95 18:54 EST Received: from sanctuary.haven.org ([205.161.40.15]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id JAA00874 for ; Fri, 17 Nov 1995 09:59:55 +1100 Received: (from dkap@localhost) by sanctuary.haven.org (8.6.11/8.6.9) id RAA21739; Thu, 16 Nov 1995 17:51:13 -0500 Date: Thu, 16 Nov 1995 17:51:13 -0500 Message-Id: <199511162251.RAA21739@sanctuary.haven.org> To: michael@memra.com CC: Daniel.Karrenberg@ripe.net, alan@gi.net, nanog@merit.edu, jnc@ginger.lcs.mit.edu, HANK@taunivm.tau.ac.il, nanog@dune.silkroad.com, big-internet@munnari.oz.au, cidrd@iepg.org, little@faline.bellcore.com In-reply-to: (message from Michael Dillon on Thu, 16 Nov 1995 13:26:52 -0800 (PST)) Subject: Re: Routing wars pending? Reply-To: dkap@haven.org Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "A Page in the Life of ..." From: Michael Dillon On Thu, 16 Nov 1995, Daniel Karrenberg wrote: > They also passed a bill once to make PI 3 or some such, didn't they? In the state where this happened it was passed by their congress but was vetoed in their senate so it never became law. Florida. I'm not sure that it was vetoed, though, I'll have to check back. (The premis of the argument put forth was a quote in the bible about a certain oasis being 30 cubits around and 10 cubits across, so PId=c solve for PI.) Dave K. (rampant trivia maven)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27217; 16 Nov 95 20:06 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa27213; 16 Nov 95 20:06 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa10742; 16 Nov 95 20:06 EST Received: from dune.silkroad.com (dune.silkroad.com [165.209.1.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id LAA02763 for ; Fri, 17 Nov 1995 11:09:52 +1100 Received: (from nanog@localhost) by dune.silkroad.com (8.6.12/8.6.9) id UAA00641 for cidrd@iepg.org; Thu, 16 Nov 1995 20:07:38 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Bass (@NANOG-LIST) Message-Id: <199511170107.UAA00641@dune.silkroad.com> Subject: Re: Routing wars pending? To: cidrd@iepg.org Date: Thu, 16 Nov 1995 20:07:38 -0500 (EST) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 420 Didn't the CIDRD-WG draft an IETF document in 1992 or was is 1994 stating that all routes should be aggregated on binary powers of PI? Or was it that all route flaps can flap no more than PI times per day? hmmmm, on second thought, help me out a little, was it? "Let's all go after a piece of the PI!!" Tim (sorry, since this thread is so faaarrrr off Hank's original post, just couldn't resist the humor :-)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04194; 16 Nov 95 22:55 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04190; 16 Nov 95 22:55 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa22174; 16 Nov 95 22:55 EST Received: from cesium.clock.org (cesium.clock.org [17.255.4.43]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id LAA03371 for ; Fri, 17 Nov 1995 11:32:16 +1100 Received: by cesium.clock.org id <5604>; Thu, 16 Nov 1995 16:32:09 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sean Doran To: kimh@internic.net, randy@psg.com Subject: Re: geographic as opposed to topologic allocation Cc: cidrd@iepg.org, help@uunet.uu.net Message-Id: <95Nov16.163209pst.5604@cesium.clock.org> Date: Thu, 16 Nov 1995 16:32:04 -0800 Dear UUNET left-hand, please meet UUNET right-hand in the form of asp@uunet.uu.net (or hank@uunet.uu.net, or jmalcolm@uunet.uu.net or a whole mess of others, including some management types like louie@uunet.uu.net, or mo@uunet.uu.net), all of whom would be happy (I'm sure) to help you sort this out. I don't want to pick on you too much, because I work in a large bureaucratic organization like yours, and so I know it's hard to keep everyone in sync. Sean. Randy Bush wrote: | Quick, before the ISOC or ITU or whomever change all this , how can I | communicate this to UUNET staff? Is a statement from the InterNIC of | "should receive address space from UUNET if possible," authoritative?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09891; 17 Nov 95 6:28 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09887; 17 Nov 95 6:28 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa12649; 17 Nov 95 6:28 EST Received: from sigma.itu.ch (sigma.itu.ch [156.106.128.30]) by nico.aarnet.edu.au (8.6.10/8.6.10) with ESMTP id VAA09635 for ; Fri, 17 Nov 1995 21:36:43 +1100 Received: from MR.ITU.CH by ITU.CH (PMDF V4.3-7 #4298) id <01HXQXN4MS9C8ZEEDH@ITU.CH>; Fri, 17 Nov 1995 11:25:50 CET Received: with PMDF-MR; Thu, 16 Nov 1995 15:56:02 CET MR-Received: by mta TIES.MUAS; Relayed; Thu, 16 Nov 1995 15:56:02 +0100 MR-Received: by mta SIGMA; Relayed; Thu, 16 Nov 1995 15:56:05 +0100 Disclose-recipients: prohibited Date: Thu, 16 Nov 1995 15:56:02 +0100 (CET) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Stephen Geis Subject: Re: 800 numbers vs. IP addresses (was Routing wars pending?) To: Alan Hannan , nanog Cc: jnc , HANK , nanog , big-internet , cidrd , little Message-id: <1402561616111995/A09137/SIGMA/119B84372600*@MHS> X-Envelope-to: cidrd@iepg.org Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Importance: normal Priority: normal UA-content-id: 119B84372600 X400-MTS-identifier: [;1402561616111995/A09137/SIGMA] Hop-count: 1 Alan Hannan asked: > What are the correlations and contrasts between our current > backbone routing problems (wrt space and # of routes) and the FCC > decision several years ago to make 1-800 numbers portable. > There is a major difference between ownership of IP network numbers and telephone number portability: the economic benefits of ownership of addresses are not comparable to those of ownership of telephone numbers. As far as I know, the economic benefits of network number ownership are confined to cost avoidance related to re-numbering. A major argument for ownership of telephone numbers (and especially freephone - e.g., 800 - numbers) is that the subscriber makes an investment (by advertising, letterhead, etc) getting knowledge of a subscriber's phone number to customers, friends, and other correspondents. Since the knowledge (as used by humans) of how to reach a "subscriber" on the Internet is encoded in a DNS name and not in an address, no comparable argument can be made for ownership of addresses. Stephen Geis ITU geis@itu.ch   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15710; 17 Nov 95 10:53 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15706; 17 Nov 95 10:53 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa04182; 17 Nov 95 10:53 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA08627; Sat, 18 Nov 1995 02:47:13 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08609; Sat, 18 Nov 1995 02:40:41 +1100 Received: from faline.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15973; Sat, 18 Nov 1995 02:40:39 +1100 (from little@faline.bellcore.com) Received: from faline (localhost [127.0.0.1]) by faline.bellcore.com (8.6.9/8.6.10) with ESMTP id KAA04630; Fri, 17 Nov 1995 10:40:31 -0500 Message-Id: <199511171540.KAA04630@faline.bellcore.com> To: Mike O'Dell Cc: big-internet@munnari.oz.au, cidrd@iepg.org Subject: Re: Routing wars pending? In-Reply-To: Your message of "Thu, 16 Nov 1995 15:38:24 EST." Date: Fri, 17 Nov 1995 10:40:19 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Little Precedence: bulk Mike, I'm not sure what you're point here is. Are you saying you don't see any parallels between 800 number portability and IP number portability concepts? Alan asked for some contrast, I (hopefully) made some Big-I relevant points (not so sure about cidr relevance) concerning impacts of naming/addressing with 800 numbers as a backdrop. The only thing being new to the long term topic dicsussion perhaps is the importance of identity persistence within a "domain". I hope nobobdy seriously considers adopting the 800 translation model (or any existing model for that matter without due consideration) as a solution in the IP environment. You make a good point that the current 800 implementation is not a valid one for IP. And a quip to consider which may be harder - is it harder to solve the IP portability problem *or* to get a solution to market in one year that (currently) performs flawlessly after deployment? -Mike > Mike O'Dell writes: > >800 portability is NOT a good analogy for IP portability. > >portability of every phone number between all countries is >a much better analogy. > >it is also much harder. > > -mo   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19927; 17 Nov 95 14:07 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19923; 17 Nov 95 14:07 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa05038; 17 Nov 95 14:07 EST Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id EAA12807 for ; Sat, 18 Nov 1995 04:17:21 +1100 Received: by rip.psg.com (Smail3.1.29.1 #1) id m0tGUPP-00031OC; Fri, 17 Nov 95 09:17 PST Message-Id: Date: Fri, 17 Nov 95 09:17 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Randy Bush To: help@uunet.uu.net Cc: cidrd@iepg.org, Kim Morla , "J.L. Martinez Estefania-Telefonica Sistemas" Subject: Re: Re: geographic as opposed to topologic allocation (TS066289) References: > After talking to Kim Hubbard, UUNET will be able to allocate your > organization non portable Class C networks, unlike the portable > set aside for South/Central America. > > Please send me a network registration template in order for > me to process your request and let me know what your account > number is with UUNET. Hi Ralph, Thanks for working on this one. And thanks to Kim and all the good folk at the CI..., oops, InterNIC. I do understand that provider-based addressing is inherently non-portable. But it is always worth stressing. I sent the usual reading list to the folk concerned. draft-hubbard-registry-guidelines-00.txt draft-ietf-cidrd-addr-ownership-04.txt draft-ietf-cidrd-ownership-02.txt draft-ietf-cidrd-private-addr-04.txt But, although I have found your service excellent in the past, I am not the customer this time. I am just the geek of last resort for some folk in Peru. So I have Cc:d them on this reply, and hope that they can carry the ball from here. If I can confuse things further, holler. Again, thanks for working on this stuff. It's a pain, but it does help the common good. randy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19940; 17 Nov 95 14:07 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19935; 17 Nov 95 14:07 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa05049; 17 Nov 95 14:07 EST Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id EAA12778 for ; Sat, 18 Nov 1995 04:05:58 +1100 Received: from godzilla.uu.net by rodan.UU.NET with SMTP id QQzqgq04905; Fri, 17 Nov 1995 12:05:24 -0500 Received: by godzilla.uu.net (leaf) id QQzqgq10215; Fri, 17 Nov 1995 12:05:22 -0500 Date: Fri, 17 Nov 1995 12:05:22 -0500 Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: UUNET Customer Liaison To: randy@psg.com Subject: Re: Re: geographic as opposed to topologic allocation (TS066289) Cc: cidrd@iepg.org, help@uunet.uu.net Reply-to: help@uunet.uu.net Please do not take the (TSXXXXX) information out of the subject header when replying to this problem. We use this number to track specific customer issues. Thank you. > To: Kim Hubbard > Cc: cidrd@iepg.org, help@uunet.uu.net > Subject: Re: geographic as opposed to topologic allocation > > > It's true there are blocks of addresses set aside for various geographical > > areas, however, if someone in Peru is connecting to UUNET than they > > should receive address space from UUNET if possible. If they were to > > request it directly from the InterNIC they would receive it from the block > > set aside for South/Central America. > > Thanks Kim, > > Quick, before the ISOC or ITU or whomever change all this , how can I > communicate this to UUNET staff? Is a statement from the InterNIC of > "should receive address space from UUNET if possible," authoritative? > Randy, After talking to Kim Hubbard, UUNET will be able to allocate your organization non portable Class C networks, unlike the portable set aside for South/Central America. Please send me a network registration template in order for me to process your request and let me know what your account number is with UUNET. =================================================================== Ralph T. Davis UNIX Technical Support Staff ++Its the File System++ UUNET Technologies ====================================================================   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06959; 18 Nov 95 4:54 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06955; 18 Nov 95 4:54 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa04803; 18 Nov 95 4:54 EST Received: from koromiko.off.connect.com.au (koromiko.off.connect.com.au [192.94.41.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with ESMTP id UAA03105 for ; Sat, 18 Nov 1995 20:04:54 +1100 Received: from [202.21.8.15] (chris.mel.interconnect.com.au [202.21.8.15]) by koromiko.off.connect.com.au with SMTP id UAA14277 (8.6.12/IDA-1.6); Sat, 18 Nov 1995 20:04:23 +1100 Message-ID: <199511180904.UAA14277@koromiko.off.connect.com.au> X-Sender: chris@koromiko.off.connect.com.au Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 18 Nov 1995 20:04:48 +1000 To: hank@taunivm.tau.ac.il Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Chris Chaundy Subject: Sharing a block between ASs Cc: cidrd@iepg.org A question related to the CIDR FAQ (which may be worth adding)... If you wish to advertise different nets within a block with two or more different ASs (for policy reasons, done with route maps, 'match ip-address' and 'set origin egp' statements), assuming the division is done on CIDR boudaries within the block, is it OK to then summarize the advertisement of these with the 'aggregate-address ... summary-only' statements (I assume that one statement would be required for each 'sub-block' corresponding to a particular AS)? Regards. -- Chris Chaundy (Network Manager) connect.com.au pty ltd, P.O. Box 2202, Caulfield, Victoria 3161, Australia Internet: chris@connect.com.au Phone: +61 3 9528-2239 Fax: +61 3 9528-5887   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11883; 20 Nov 95 8:34 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11879; 20 Nov 95 8:34 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa08653; 20 Nov 95 8:34 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA12278; Tue, 21 Nov 1995 00:28:13 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA12223; Tue, 21 Nov 1995 00:16:50 +1100 Received: from mailhost.pipex.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13116; Tue, 21 Nov 1995 00:16:46 +1100 (from keith@pipex.com) Received: from pipe.pipex.net (actually mailhost.pipex.net) by pipe.pipex.net with SMTP (PP); Mon, 20 Nov 1995 13:16:22 +0000 Received: by pipe.pipex.net (8.6.12/PIPEX simple 1.22) id NAA11997; Mon, 20 Nov 1995 13:16:12 GMT Message-Id: <199511201316.NAA11997@pipe.pipex.net> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Mitchell Date: Mon, 20 Nov 1995 13:16:12 +0000 In-Reply-To: <199511171540.KAA04630@faline.bellcore.com> X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: Mike Little , Mike O'Dell Subject: Re: Routing wars pending? Cc: big-internet@munnari.oz.au, cidrd@iepg.org Precedence: bulk In <199511171540.KAA04630@faline.bellcore.com>, wrote: > You make a good point that the current 800 implementation > is not a valid one for IP. > > Mike O'Dell writes: > > > >800 portability is NOT a good analogy for IP portability. > > > >portability of every phone number between all countries is > >a much better analogy. > > > >it is also much harder. A better telephony example perhaps is that of GSM roaming, where there is no mapping from a a "logical" 800 number to a physical geographic code identifying the end-point. Instead the phone is still addressed by it's home country and area code, even when it is in another country. I think the routing is currently done by host redirection. I suspect that currently roamed mobile phone use is sufficiently rare that there are not scaling problems with this approach at present, but with GSM growth comparable to Internet growth I think they may have a few headaches ahead... However, mobility is a seperate issue being addressed elsewhere in the IP world, I guess this is where the analogy breaks down. Keith Mitchell Head of Engineering PIPEX International keith@pipex.com 216 The Science Park Cambridge, UK Phone: +44 1223-250311 Fax: +44 1223-250373 A subsidiary of UUNET Technologies Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09509; 21 Nov 95 6:56 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09505; 21 Nov 95 6:56 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa07004; 21 Nov 95 6:56 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA13537; Tue, 21 Nov 1995 22:49:04 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA13508; Tue, 21 Nov 1995 22:37:32 +1100 Received: from ncc.ripe.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04305; Tue, 21 Nov 1995 22:37:21 +1100 (from geertj@ripe.net) Received: from berklix.ripe.net by ncc.ripe.net with SMTP id AA02100 (5.65a/NCC-2.30); Tue, 21 Nov 1995 12:36:34 +0100 Received: from berklix.ripe.net (geertj@localhost.ripe.net [127.0.0.1]) by berklix.ripe.net (8.6.12/8.6.9) with ESMTP id UAA00300; Mon, 20 Nov 1995 20:53:21 +0100 Message-Id: <199511201953.UAA00300@berklix.ripe.net> To: Keith Mitchell Cc: big-internet@munnari.oz.au, cidrd@iepg.org Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: Re: Routing wars pending? In-Reply-To: Your message of "Mon, 20 Nov 1995 13:16:12 GMT." <199511201316.NAA11997@pipe.pipex.net> Date: Mon, 20 Nov 1995 20:53:20 +0100 X-Orig-Sender: GeertJan.deGroot@ripe.net Precedence: bulk On Mon, 20 Nov 1995 13:16:12 +0000 Keith Mitchell wrote: > In <199511171540.KAA04630@faline.bellcore.com>, wrote: > A better telephony example perhaps is that of GSM roaming, where > there is no mapping from a a "logical" 800 number to a physical > geographic code identifying the end-point. Instead the phone is still > addressed by it's home country and area code, even when it is > in another country. I think the routing is currently done by host > redirection. > > I suspect that currently roamed mobile phone use is sufficiently rare > that there are not scaling problems with this approach at present, > but with GSM growth comparable to Internet growth I think they may > have a few headaches ahead... GSM, at least in the Netherlands, uses the priciple that if you're out of your 'region', that you pay the transit between the home-country and the place you are. E.g. if a Dutch subscriber is in France and receives a call from the Netherlands, then the caller pays mobile phone rates for a Dutch mobile call, and the GSM owner pays a rate from the Netherlands to France, i.e. the GSM owner pays for its mobility and the extra transit involved. We could do the same with IP (encapsulating it), but somehow I feel that this approach will never be popular, either with GSM or with IP... Geert Jan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05442; 27 Nov 95 0:25 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05438; 27 Nov 95 0:25 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa01858; 27 Nov 95 0:25 EST Received: from netaxs.com (netaxs.com [198.69.186.1]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id PAA09418 for ; Mon, 27 Nov 1995 15:02:12 +1100 Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id XAA05234; Sun, 26 Nov 1995 23:00:49 -0500 Date: Sun, 26 Nov 1995 23:00:49 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Avi Freedman Message-Id: <199511270400.XAA05234@netaxs.com> To: big-internet@munnari.oz.au, cidrd@iepg.org, nanog@merit.edu Subject: CIDR Aggregation Tool Cc: freedman@netaxs.com Well, after observing the debates about What To Do About The Routing Table Size, I decided to work on some informal tools to examine the current routing table space for possible aggregations. Right now, the raw data is the routing table from the Net Access MAE-East router. It only searches for aggregates /15 < x < /25 right now - ignoring some fairly obvious aggregation-suggestions in the /8 < x < /16 range. The results are up at http://routes.netaxs.com and the some of the caveats are listed on the web page, but are: 1) When the Net Access MAE-East router has multiple identical routes that point to the same next-hop (192.41.177.x), the system only uses the one first listed in the cisco 'sho ip bgp summ' output - even though that's not always the 'best' route. 2) When an AS advertises both an aggregate and a specific, the specific is 'dropped' by the aggregator. If the input is: {205.89.10.128/17, 205.89.10.130}, the output will be: {205.89.10.128/17} (205.89.10.130 will be dropped). 3) The source of data is the Net Access MAE-East router routing table, and we don't peer with all parties at MAE-East directly - thus, it's possible that the system catches aggregations that are impossible because they're announced to a 3rd party via different paths - but an informal look around doesn't appear to indicate that. 4) The system goes by next-hop rather than by AS-Path. There seems to be a good correlation, but ... Also, the final disclaimer: I've examined the results and they *look* reasonable. But I haven't written tester-tools to attempt to verify by another algorithm that the results are correct. Here's the table at the end of the web page: Before After Run Agg. Run 192.41.177.110 ibm 81 68 192.41.177.115 digex 98 98 192.41.177.120 eu.net 949 775 192.41.177.125 nsn.nasa 126 112 192.41.177.140 ans 2146 1425 192.41.177.145 agis 539 304 192.41.177.150 uscyber 2 2 192.41.177.160 interpath 2 2 192.41.177.170 net99 309 246 192.41.177.180 mci 2 2 192.41.177.181 mci 8963 6828 192.41.177.190 pipex 367 308 192.41.177.210 netcom 370 348 192.41.177.235 psi 1 1 192.41.177.240 icp 4499 3712 192.41.177.241 sprintlink 6429 4694 192.41.177.245 psi 1491 1098 192.41.177.249 alternet 3971 3148 192.41.177.251 es.net 96 88 192.41.177.252 es.net 122 101 192.41.177.6 suranet 470 445 192.41.177.70 internex 1 1 192.41.177.80 ios 10 8 192.41.177.85 cais 184 158 192.41.177.86 hlc 354 243 192.41.177.89 energis 2 2 192.41.177.95 delphi 3 3 A final note: We're open to {Additional static sources of route tables at MAE-East; Additional static sources of route tables at {MAE-West, Pennsauken, or the PacBell NAP}; and dynamic (i.e. the vty password so we can run a sho ip bgp summ every so often) sources at any of the MAEs or NAPs. If we get good feedback, we may automate this to run overnight and keep a history. Avi Freedman freedman@netaxs.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06476; 27 Nov 95 2:36 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ab06472; 27 Nov 95 2:36 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa03557; 27 Nov 95 2:36 EST Received: from lovefm.reston.mci.net (lovefm.Reston.mci.net [166.45.2.37]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id RAA12007 for ; Mon, 27 Nov 1995 17:35:03 +1100 Received: from localhost (localhost.mci.net [127.0.0.1]) by lovefm.reston.mci.net (8.6.12/8.6.6) with ESMTP id BAA01017 for ; Mon, 27 Nov 1995 01:34:55 -0500 Message-Id: <199511270634.BAA01017@lovefm.reston.mci.net> To: cidrd@iepg.org Subject: In the spirit... Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Bates X-Phone: +1 703 715 7521 Date: Mon, 27 Nov 1995 01:34:55 -0500 X-Orig-Sender: tony@mci.net Here's the latest top-30. Looks like UUNET-CANADA dropped a fair bit from last time. --Tony. ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 1047 576 471 45.0% i*internet AS174 1493 1053 440 29.5% Performance Systems International AS544 740 524 216 29.2% The DataNet IP Service AS3848 425 236 189 44.5% WORLDLINX AS568 759 572 187 24.6% Milnet FIXes--144(W)/145(E) AS4628 240 54 186 77.5% APNIC-AS-BLOCK AS1324 465 287 178 38.3% ANS New York City - DNSS 35 AS97 506 338 168 33.2% JvNCnet AS3602 285 175 110 38.6% Intergrated Network Services Inc. AS4230 195 93 102 52.3% EMBRATEL-BR AS1717 649 556 93 14.3% RENATER AS1691 203 115 88 43.3% Advanced Network and Services (AN AS560 397 310 87 21.9% BBN Planet, New England Region (N AS1849 283 196 87 30.7% PIPEX, Public IP EXchange AS2044 171 85 86 50.3% WORLDNET-AS AS2386 219 134 85 38.8% INS-AS AS1257 273 192 81 29.7% SWIPnet Swedish IP Network AS1204 130 52 78 60.0% SUNYNET-ASN-AS AS600 254 182 72 28.3% OARnet AS AS1759 217 147 70 32.3% The DataNet IP Service AS3258 163 94 69 42.3% contrib.net section A AS1930 150 88 62 41.3% RCCN-NET AS3397 104 43 61 58.7% EMI-AS AS1899 152 96 56 36.8% Fnet, EUnet-France AS719 237 184 53 22.4% LANLINK autonomous system AS813 188 138 50 26.6% UUNET Canada (ASN-UUNETCA-AS1) AS549 245 195 50 20.4% ONet Backbone AS3354 197 147 50 25.4% THENET-AS-1 AS2018 170 121 49 28.8% The research and academic network AS1327 102 53 49 48.0% ANS Washington D.C. - DNSS 59   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12965; 27 Nov 95 9:17 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12961; 27 Nov 95 9:17 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa16530; 27 Nov 95 9:17 EST Received: from cesium.clock.org (cesium.clock.org [17.255.4.43]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id XAA15569 for ; Mon, 27 Nov 1995 23:52:11 +1100 Received: by cesium.clock.org id <5605>; Mon, 27 Nov 1995 04:51:39 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sean Doran To: Tony.Bates@mci.net, cidrd@iepg.org Subject: Re: In the spirit... Cc: debbie@worldlinx.com, dhoward@worldlinx.com, help@worldlinx.com, jim@worldlinx.com Message-Id: <95Nov27.045139pst.5605@cesium.clock.org> Date: Mon, 27 Nov 1995 04:51:36 -0800 This is excellent news. Good work, Guy Middleton and the rest of the AlterNet/UUNET Canada gang! Now, what about i*internet and WORLDLINX? The latter I am considering doing aggressive proxy-aggregation on because frankly they simply are utterly non-responsive, and I am hoping that perhaps they can feel a bit under pressure now that one of their competitors is doing the right thing. The former has Eric Carroll there and he has been saying for some time -- several lists now -- that he was going to do something, but right now things are _worse_ than when he claimed that. Yoo hoo, Eric, what gives? Sean. - -- From smd Mon Nov 27 00:27:37 1995 Return-Path: aarnet.edu.au!owner-cidrd Received: from nico.aarnet.edu.au ([139.130.204.16]) by cesium.clock.org with SMTP id <5600>; Mon, 27 Nov 1995 00:27:27 -0800 Received: from lovefm.reston.mci.net (lovefm.Reston.mci.net [166.45.2.37]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id RAA12007 for ; Mon, 27 Nov 1995 17:35:03 +1100 Received: from localhost (localhost.mci.net [127.0.0.1]) by lovefm.reston.mci.net (8.6.12/8.6.6) with ESMTP id BAA01017 for ; Mon, 27 Nov 1995 01:34:55 -0500 Message-Id: <199511270634.BAA01017@lovefm.reston.mci.net> To: cidrd@iepg.org Subject: In the spirit... From: Tony Bates X-Phone: +1 703 715 7521 Date: Sun, 26 Nov 1995 22:34:55 -0800 Sender: tony@mci.net Status: R Here's the latest top-30. Looks like UUNET-CANADA dropped a fair bit from last time. --Tony. ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 1047 576 471 45.0% i*internet AS174 1493 1053 440 29.5% Performance Systems International AS544 740 524 216 29.2% The DataNet IP Service AS3848 425 236 189 44.5% WORLDLINX AS568 759 572 187 24.6% Milnet FIXes--144(W)/145(E) AS4628 240 54 186 77.5% APNIC-AS-BLOCK AS1324 465 287 178 38.3% ANS New York City - DNSS 35 AS97 506 338 168 33.2% JvNCnet AS3602 285 175 110 38.6% Intergrated Network Services Inc. AS4230 195 93 102 52.3% EMBRATEL-BR AS1717 649 556 93 14.3% RENATER AS1691 203 115 88 43.3% Advanced Network and Services (AN AS560 397 310 87 21.9% BBN Planet, New England Region (N AS1849 283 196 87 30.7% PIPEX, Public IP EXchange AS2044 171 85 86 50.3% WORLDNET-AS AS2386 219 134 85 38.8% INS-AS AS1257 273 192 81 29.7% SWIPnet Swedish IP Network AS1204 130 52 78 60.0% SUNYNET-ASN-AS AS600 254 182 72 28.3% OARnet AS AS1759 217 147 70 32.3% The DataNet IP Service AS3258 163 94 69 42.3% contrib.net section A AS1930 150 88 62 41.3% RCCN-NET AS3397 104 43 61 58.7% EMI-AS AS1899 152 96 56 36.8% Fnet, EUnet-France AS719 237 184 53 22.4% LANLINK autonomous system AS813 188 138 50 26.6% UUNET Canada (ASN-UUNETCA-AS1) AS549 245 195 50 20.4% ONet Backbone AS3354 197 147 50 25.4% THENET-AS-1 AS2018 170 121 49 28.8% The research and academic network AS1327 102 53 49 48.0% ANS Washington D.C. - DNSS 59   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15902; 27 Nov 95 10:00 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15897; 27 Nov 95 10:00 EST Received: from [128.250.22.5] by CNRI.Reston.VA.US id aa18061; 27 Nov 95 10:00 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA21192; Tue, 28 Nov 1995 01:50:38 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA21174; Tue, 28 Nov 1995 01:40:24 +1100 Received: from clone3.Reston.mci.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03453; Tue, 28 Nov 1995 01:40:15 +1100 (from enke@mci.net) Received: from localhost ([127.0.0.1]) by clone3.Reston.mci.net (8.6.12/8.6.6) with ESMTP id JAA27275; Mon, 27 Nov 1995 09:39:36 -0500 Message-Id: <199511271439.JAA27275@clone3.Reston.mci.net> To: Avi Freedman Cc: big-internet@munnari.oz.au, cidrd@iepg.org, nanog@merit.edu, enke@mci.net Subject: Re: CIDR Aggregation Tool In-Reply-To: Your message of "Sun, 26 Nov 1995 23:00:49 EST." <199511270400.XAA05234@netaxs.com> Date: Mon, 27 Nov 1995 09:39:35 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Enke Chen Precedence: bulk Avi, Did you not see the aggregation report by Tony Bates on cidrd posted periodically for the last couple of years? It lists aggregation gains for each origin AS, rather than the BGP neighbor in your numbers. IMHO, numbers based on origin AS is much more useful. If you need to invent wheels, let us at least invent better wheels :-) -- Enke Date: Mon, 27 Nov 1995 01:34:55 EST To: cidrd@iepg.org From: Tony Bates Subject: In the spirit... Here's the latest top-30. Looks like UUNET-CANADA dropped a fair bit from last time. --Tony. ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 1047 576 471 45.0% i*internet AS174 1493 1053 440 29.5% Performance Systems International AS544 740 524 216 29.2% The DataNet IP Service AS3848 425 236 189 44.5% WORLDLINX AS568 759 572 187 24.6% Milnet FIXes--144(W)/145(E) AS4628 240 54 186 77.5% APNIC-AS-BLOCK AS1324 465 287 178 38.3% ANS New York City - DNSS 35 AS97 506 338 168 33.2% JvNCnet AS3602 285 175 110 38.6% Intergrated Network Services Inc. AS4230 195 93 102 52.3% EMBRATEL-BR AS1717 649 556 93 14.3% RENATER [....] > Date: Sun, 26 Nov 1995 23:00:49 -0500 > From: Avi Freedman > To: big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu > CC: freedman@netaxs.com > Well, after observing the debates about What To Do About The Routing Table > Size, I decided to work on some informal tools to examine the current > routing table space for possible aggregations. > > Right now, the raw data is the routing table from the Net Access MAE-East > router. > > It only searches for aggregates /15 < x < /25 right now - ignoring some > fairly obvious aggregation-suggestions in the /8 < x < /16 range. > > The results are up at http://routes.netaxs.com and the some of the caveats > are listed on the web page, but are: > > 1) When the Net Access MAE-East router has multiple identical routes that > point to the same next-hop (192.41.177.x), the system only uses the one > first listed in the cisco 'sho ip bgp summ' output - even though that's > not always the 'best' route. > > 2) When an AS advertises both an aggregate and a specific, the specific > is 'dropped' by the aggregator. If the input is: > {205.89.10.128/17, 205.89.10.130}, the output will be: > {205.89.10.128/17} (205.89.10.130 will be dropped). > > 3) The source of data is the Net Access MAE-East router routing table, > and we don't peer with all parties at MAE-East directly - thus, it's > possible that the system catches aggregations that are impossible > because they're announced to a 3rd party via different paths - but > an informal look around doesn't appear to indicate that. > > 4) The system goes by next-hop rather than by AS-Path. There seems to > be a good correlation, but ... > > Also, the final disclaimer: I've examined the results and they *look* > reasonable. But I haven't written tester-tools to attempt to verify > by another algorithm that the results are correct. > > Here's the table at the end of the web page: > > Before After > Run Agg. Run > 192.41.177.110 ibm 81 68 > 192.41.177.115 digex 98 98 > 192.41.177.120 eu.net 949 775 > 192.41.177.125 nsn.nasa 126 112 > 192.41.177.140 ans 2146 1425 > 192.41.177.145 agis 539 304 > 192.41.177.150 uscyber 2 2 > 192.41.177.160 interpath 2 2 > 192.41.177.170 net99 309 246 > 192.41.177.180 mci 2 2 > 192.41.177.181 mci 8963 6828 > 192.41.177.190 pipex 367 308 > 192.41.177.210 netcom 370 348 > 192.41.177.235 psi 1 1 > 192.41.177.240 icp 4499 3712 > 192.41.177.241 sprintlink 6429 4694 > 192.41.177.245 psi 1491 1098 > 192.41.177.249 alternet 3971 3148 > 192.41.177.251 es.net 96 88 > 192.41.177.252 es.net 122 101 > 192.41.177.6 suranet 470 445 > 192.41.177.70 internex 1 1 > 192.41.177.80 ios 10 8 > 192.41.177.85 cais 184 158 > 192.41.177.86 hlc 354 243 > 192.41.177.89 energis 2 2 > 192.41.177.95 delphi 3 3 > > A final note: We're open to {Additional static sources of route tables at > MAE-East; Additional static sources of route tables at {MAE-West, Pennsauken, > or the PacBell NAP}; and dynamic (i.e. the vty password so we can run > a sho ip bgp summ every so often) sources at any of the MAEs or NAPs. > > If we get good feedback, we may automate this to run overnight and keep > a history. > > Avi Freedman > freedman@netaxs.com >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20544; 27 Nov 95 11:22 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20537; 27 Nov 95 11:22 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa20807; 27 Nov 95 11:22 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA21287; Tue, 28 Nov 1995 03:12:48 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA21258; Tue, 28 Nov 1995 03:04:28 +1100 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09106; Tue, 28 Nov 1995 03:04:26 +1100 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id LAA08941; Mon, 27 Nov 1995 11:04:21 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Avi Freedman Message-Id: <199511271604.LAA08941@netaxs.com> Subject: Re: CIDR Aggregation Tool To: Enke Chen Date: Mon, 27 Nov 1995 11:04:20 -0500 (EST) Cc: big-internet@munnari.oz.au, cidrd@iepg.org, nanog@merit.edu, enke@mci.net In-Reply-To: <199511271439.JAA27275@clone3.Reston.mci.net> from "Enke Chen" at Nov 27, 95 09:39:35 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 897 Precedence: bulk > Avi, > Did you not see the aggregation report by Tony Bates on cidrd > posted periodically for the last couple of years? It lists > aggregation gains for each origin AS, rather than the BGP > neighbor in your numbers. IMHO, numbers based on origin AS > is much more useful. > > If you need to invent wheels, let us at least invent better > wheels :-) > > -- Enke No, I missed the ASnum-based report by Tony on cidrd. In any case, I thought it would be useful to try to gather the data independently on real data in use by our network... Also, the report based on ASN tends to miss JVNC etc... which can be aggregated by their transit provider at the peering/exchange locations. Reports based on just next-hop seem to catch the top-level aggregation possibilities (i.e. a customer of JVNC & a customer of some other ISP might have adjacent /24s that could be aggregated)... Avi   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21098; 27 Nov 95 11:44 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21094; 27 Nov 95 11:44 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa21413; 27 Nov 95 11:43 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA21322; Tue, 28 Nov 1995 03:32:00 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA21295; Tue, 28 Nov 1995 03:17:48 +1100 Received: from aero.branch.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23476; Tue, 28 Nov 1995 03:17:36 +1100 (from jon@branch.com) Received: by aero.branch.com (mail) id m0tK6FH-000Nj6C; Mon, 27 Nov 95 11:17 EST Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jon Zeeff Subject: Re: CIDR Aggregation Tool To: Avi Freedman Date: Mon, 27 Nov 1995 11:17:30 -0500 (EST) Cc: big-internet@munnari.oz.au, cidrd@iepg.org, nanog@merit.edu, freedman@netaxs.com In-Reply-To: <199511270400.XAA05234@netaxs.com> from "Avi Freedman" at Nov 26, 95 11:00:49 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 402 Precedence: bulk Perhaps this is just a small error that has to be accepted in your measurements, but we are dual homed and require both the aggregate and the specific. > 2) When an AS advertises both an aggregate and a specific, the specific > is 'dropped' by the aggregator. If the input is: > {205.89.10.128/17, 205.89.10.130}, the output will be: > {205.89.10.128/17} (205.89.10.130 will be dropped).   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21483; 27 Nov 95 11:57 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21478; 27 Nov 95 11:57 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa21858; 27 Nov 95 11:57 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA21364; Tue, 28 Nov 1995 03:50:26 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA21346; Tue, 28 Nov 1995 03:47:02 +1100 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01667; Tue, 28 Nov 1995 03:47:00 +1100 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id LAA10434; Mon, 27 Nov 1995 11:46:54 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Avi Freedman Message-Id: <199511271646.LAA10434@netaxs.com> Subject: Re: CIDR Aggregation Tool To: Avi Freedman Date: Mon, 27 Nov 1995 11:46:53 -0500 (EST) Cc: enke@mci.net, big-internet@munnari.oz.au, cidrd@iepg.org, nanog@merit.edu In-Reply-To: <199511271604.LAA08941@netaxs.com> from "Avi Freedman" at Nov 27, 95 11:04:20 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 249 Precedence: bulk > Also, the report based on ASN tends to miss JVNC etc... which > can be aggregated by their transit provider at the peering/exchange > locations. Oops. I meant to say "the report based on next-hop", not "the report based on ASN". Sorry... Avi   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21546; 27 Nov 95 11:59 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21542; 27 Nov 95 11:59 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa21909; 27 Nov 95 11:59 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA21386; Tue, 28 Nov 1995 03:51:35 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA21343; Tue, 28 Nov 1995 03:44:23 +1100 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA30129; Tue, 28 Nov 1995 03:44:19 +1100 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id LAA10333; Mon, 27 Nov 1995 11:44:13 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Avi Freedman Message-Id: <199511271644.LAA10333@netaxs.com> Subject: Re: CIDR Aggregation Tool To: Jon Zeeff Date: Mon, 27 Nov 1995 11:44:12 -0500 (EST) Cc: big-internet@munnari.oz.au, cidrd@iepg.org, nanog@merit.edu In-Reply-To: from "Jon Zeeff" at Nov 27, 95 11:17:30 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1372 Precedence: bulk > Perhaps this is just a small error that has to be accepted in your > measurements, but we are dual homed and require both the aggregate and > the specific. > > > 2) When an AS advertises both an aggregate and a specific, the specific > > is 'dropped' by the aggregator. If the input is: > > {205.89.10.128/17, 205.89.10.130}, the output will be: > > {205.89.10.128/17} (205.89.10.130 will be dropped). The 205.88.10.128 was a random example. I hope that's not you :) There are no "value" judgements made by the tool - it's just suggesting aggregates. And if we see an aggregate and a specific, both set to the same next-hop, it's quite likely that it's the same AS announcing both routes, and that they (your transit provider(s)) could do the aggregation themselves - but the tool *is* deficient in that right now it doesn't consider AS-paths. As an example, picking an IP for branch.com (198.111.253.37): Our route table has: *> 198.111.252.0 192.41.177.145 <--- agis *> 198.111.252.0/22 192.41.177.181 <--- mci *> 198.111.253.0 192.41.177.145 <--- agis *> 198.111.255.0 192.41.177.145 <--- agis So if 198.111.252/23 is suggested as an aggregate for the 192.41.177.145 (AGIS) target, that's because it looks like AGIS could in fact announce 198.111.22.0/23 instead of 198.111.252/0 and 198.111.253.0. Avi   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23153; 27 Nov 95 13:17 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23144; 27 Nov 95 13:17 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa23639; 27 Nov 95 13:17 EST Received: from cesium.clock.org (cesium.clock.org [17.255.4.43]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id EAA17604 for ; Tue, 28 Nov 1995 04:18:21 +1100 Received: by cesium.clock.org id <5606>; Mon, 27 Nov 1995 09:18:12 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sean Doran To: enke@mci.net, freedman@netaxs.com Subject: Re: CIDR Aggregation Tool Cc: cidrd@iepg.org Message-Id: <95Nov27.091812pst.5606@cesium.clock.org> Date: Mon, 27 Nov 1995 09:18:01 -0800 [destinations pruned to CIDRD] Enke - One nice tweak I played with for a while the last time I had anything remotely like time to do ad hoc coding was figuring out which ASes were essentially unnecessary with respect to global routing. Curtis and Daniel will say that this requires a routing registry, and they may be right, however, armed with various views, one can pretty much tell that there are numbers of ASes which could be aggregated together somewhere upstream. In fact, anything in our newer (and nonportable) CIDR blocks are aggregated with respect to outbound announcements from AS1239, so a number of holes caused by customers needing to do BGP with us are simply never seen by the rest of the world. Catching this from the outside is awkward (it requires knowing essentially what CIDR blocks belong to whom, which is a function mostly filled by the current address allocation registries), but anything that can identify a large aggregatable chunk, particularly a newer chunk, even at the level of a neighbour at MAE-EAST is a good move, imho. Sean.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23196; 27 Nov 95 13:18 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23192; 27 Nov 95 13:18 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa23657; 27 Nov 95 13:18 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA21517; Tue, 28 Nov 1995 05:10:39 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA21476; Tue, 28 Nov 1995 04:53:16 +1100 Received: from aero.branch.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03589; Tue, 28 Nov 1995 04:53:11 +1100 (from jon@branch.com) Received: by aero.branch.com (mail) id m0tK7jS-000Nj7C; Mon, 27 Nov 95 12:52 EST Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jon Zeeff Subject: Re: CIDR Aggregation Tool To: Avi Freedman Date: Mon, 27 Nov 1995 12:52:45 -0500 (EST) Cc: jon@branch.com, big-internet@munnari.oz.au, cidrd@iepg.org, nanog@merit.edu In-Reply-To: <199511271644.LAA10333@netaxs.com> from "Avi Freedman" at Nov 27, 95 11:44:12 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 751 Precedence: bulk > Our route table has: > *> 198.111.252.0 192.41.177.145 <--- agis > *> 198.111.252.0/22 192.41.177.181 <--- mci > *> 198.111.253.0 192.41.177.145 <--- agis > *> 198.111.255.0 192.41.177.145 <--- agis This isn't what agis is supposed to be announcing, I'll have to ask them again to announce 198.111.252/22. There's a couple less routes already :-). Once that is fixed, further aggregation of 198.111.252.0 (say into 198.111/16, as a non real example) would change our routing (in ways we don't want it changed), even with your "next hop the same" criteria because of the additional meaning that specifics have in terms of priority. I agree that your tool is usefull in identifying _potential_ savings.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23573; 27 Nov 95 13:37 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23569; 27 Nov 95 13:37 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa23991; 27 Nov 95 13:37 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA21562; Tue, 28 Nov 1995 05:30:48 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA21527; Tue, 28 Nov 1995 05:14:21 +1100 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08304; Tue, 28 Nov 1995 05:14:17 +1100 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id NAA13291; Mon, 27 Nov 1995 13:04:17 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Avi Freedman Message-Id: <199511271804.NAA13291@netaxs.com> Subject: Re: CIDR Aggregation Tool To: Jon Zeeff Date: Mon, 27 Nov 1995 13:04:14 -0500 (EST) Cc: jon@branch.com, big-internet@munnari.oz.au, cidrd@iepg.org, nanog@merit.edu In-Reply-To: from "Jon Zeeff" at Nov 27, 95 12:52:45 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1203 Precedence: bulk [Please take any other responses just to cidrd. This is copied to big-inet and nanog so people will see the followup request. I just wanted the announcement to go out maximally, but the details and responses are of no interet to nanog as a whole...] > > Our route table has: > > *> 198.111.252.0 192.41.177.145 <--- agis > > *> 198.111.252.0/22 192.41.177.181 <--- mci > > *> 198.111.253.0 192.41.177.145 <--- agis > > *> 198.111.255.0 192.41.177.145 <--- agis > > This isn't what agis is supposed to be announcing, I'll have to > ask them again to announce 198.111.252/22. There's a couple less > routes already :-). > > Once that is fixed, further aggregation of 198.111.252.0 (say into > 198.111/16, as a non real example) would change our routing (in > ways we don't want it changed), even with your "next hop the same" > criteria because of the additional meaning that specifics have in > terms of priority. Well, we only see 198.111.252, 253, and 255 from AGIS, so there's no danger of AGIS over-aggregating even if they combined 252 & 253... > I agree that your tool is usefull in identifying _potential_ savings. That's all it's for. Avi   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23828; 27 Nov 95 13:47 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23824; 27 Nov 95 13:47 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa24244; 27 Nov 95 13:47 EST Received: from clone3.Reston.mci.net (clone3.Reston.mci.net [166.45.3.38]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id EAA17825 for ; Tue, 28 Nov 1995 04:44:16 +1100 Received: from localhost ([127.0.0.1]) by clone3.Reston.mci.net (8.6.12/8.6.6) with ESMTP id MAA27589; Mon, 27 Nov 1995 12:43:38 -0500 Message-Id: <199511271743.MAA27589@clone3.Reston.mci.net> To: Sean Doran cc: enke@mci.net, freedman@netaxs.com, cidrd@iepg.org Subject: Re: CIDR Aggregation Tool In-reply-to: Your message of "Mon, 27 Nov 1995 09:18:01 PST." <95Nov27.091812pst.5606@cesium.clock.org> Date: Mon, 27 Nov 1995 12:43:38 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Enke Chen Sean, I can see that aggregation at transit provider level is useful, but it is dangerous and could easily cause connectivity problems if not done with coordination. Also, I am not sure if it is something that we need to do at this time. Looking at the routing table these days, it seems to me that a safer and simpler approach is for origin ASs to aggregate. The benefit could be a reduction of routing table size by a few thousands. -- Enke > Date: Mon, 27 Nov 1995 09:18:01 -0800 > From: Sean Doran > To: enke@mci.net, freedman@netaxs.com > CC: cidrd@iepg.org > [destinations pruned to CIDRD] > > Enke - > > One nice tweak I played with for a while the last time I > had anything remotely like time to do ad hoc coding was > figuring out which ASes were essentially unnecessary with > respect to global routing. > > Curtis and Daniel will say that this requires a routing > registry, and they may be right, however, armed with various > views, one can pretty much tell that there are numbers of ASes > which could be aggregated together somewhere upstream. > > In fact, anything in our newer (and nonportable) CIDR > blocks are aggregated with respect to outbound announcements > from AS1239, so a number of holes caused by customers needing > to do BGP with us are simply never seen by the rest of the > world. > > Catching this from the outside is awkward (it requires > knowing essentially what CIDR blocks belong to whom, which > is a function mostly filled by the current address allocation > registries), but anything that can identify a large > aggregatable chunk, particularly a newer chunk, even at the > level of a neighbour at MAE-EAST is a good move, imho. > > Sean. >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25026; 27 Nov 95 14:20 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25022; 27 Nov 95 14:20 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa25171; 27 Nov 95 14:19 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA21622; Tue, 28 Nov 1995 06:10:45 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA21584; Tue, 28 Nov 1995 05:50:30 +1100 Received: from brookfield-ef0.brookfield.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05636; Tue, 28 Nov 1995 05:50:28 +1100 (from curtis@brookfield.ans.net) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.12) with ESMTP id NAA01164; Mon, 27 Nov 1995 13:50:17 -0500 Message-Id: <199511271850.NAA01164@brookfield.ans.net> To: Avi Freedman Cc: big-internet@munnari.oz.au, cidrd@iepg.org, nanog@merit.edu Reply-To: curtis@ans.net Subject: Re: CIDR Aggregation Tool In-Reply-To: Your message of "Sun, 26 Nov 1995 23:00:49 EST." <199511270400.XAA05234@netaxs.com> Date: Mon, 27 Nov 1995 13:50:17 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Precedence: bulk Avi, While this is useful as a metric of the degree of aggregation, it is not sufficient to configure aggregation. This is still useful as a means to look at where improvement may be needed. Please don't get me wrong in pointing out that there are limits to the applicability, this *is* useful. In message <199511270400.XAA05234@netaxs.com>, Avi Freedman writes: > Well, after observing the debates about What To Do About The Routing Table > Size, I decided to work on some informal tools to examine the current > routing table space for possible aggregations. > > Right now, the raw data is the routing table from the Net Access MAE-East > router. > > It only searches for aggregates /15 < x < /25 right now - ignoring some > fairly obvious aggregation-suggestions in the /8 < x < /16 range. > > The results are up at http://routes.netaxs.com and the some of the caveats > are listed on the web page, but are: > > 1) When the Net Access MAE-East router has multiple identical routes that > point to the same next-hop (192.41.177.x), the system only uses the one > first listed in the cisco 'sho ip bgp summ' output - even though that's > not always the 'best' route. The routing table seen at one place in the Internet is insufficient to determine whether aggregation is possible. Part of the problem is that equally specific alternate paths are supressed until primary connectivity is lost. You may not see alternate paths for multihomed sites that would prevent aggregation. > 2) When an AS advertises both an aggregate and a specific, the specific > is 'dropped' by the aggregator. If the input is: > {205.89.10.128/17, 205.89.10.130}, the output will be: > {205.89.10.128/17} (205.89.10.130 will be dropped). This is often done to allow a multihomed component of an aggregate to be routed correctly while still providing the backup path, or allowing load splitting across providers (usually load split by AS path filtering or more simply by AS path length). There is no way to tell a mistake from this being done intentionally. > 3) The source of data is the Net Access MAE-East router routing table, > and we don't peer with all parties at MAE-East directly - thus, it's > possible that the system catches aggregations that are impossible > because they're announced to a 3rd party via different paths - but > an informal look around doesn't appear to indicate that. > > 4) The system goes by next-hop rather than by AS-Path. There seems to > be a good correlation, but ... You really need to take into account AS path. As far back as 1992 we've seen grossly optimistic estimates based solely on next hop at single points (including estimates from me in June/July 1992). In effect what you have is the degree of aggregation possible if the aggregartion boundry was extended around the entire rest of the world (or at least everyone that peered directly with you at the point of measurement). What can be aggregated according to such an estimate will vary according to who is making the measurement and where. > Also, the final disclaimer: I've examined the results and they *look* > reasonable. But I haven't written tester-tools to attempt to verify > by another algorithm that the results are correct. > > Here's the table at the end of the web page: > > Before After > Run Agg. Run > 192.41.177.110 ibm 81 68 > 192.41.177.115 digex 98 98 > 192.41.177.120 eu.net 949 775 > 192.41.177.125 nsn.nasa 126 112 > 192.41.177.140 ans 2146 1425 > 192.41.177.145 agis 539 304 > 192.41.177.150 uscyber 2 2 > 192.41.177.160 interpath 2 2 > 192.41.177.170 net99 309 246 > 192.41.177.180 mci 2 2 > 192.41.177.181 mci 8963 6828 > 192.41.177.190 pipex 367 308 > 192.41.177.210 netcom 370 348 > 192.41.177.235 psi 1 1 > 192.41.177.240 icp 4499 3712 > 192.41.177.241 sprintlink 6429 4694 > 192.41.177.245 psi 1491 1098 > 192.41.177.249 alternet 3971 3148 > 192.41.177.251 es.net 96 88 > 192.41.177.252 es.net 122 101 > 192.41.177.6 suranet 470 445 > 192.41.177.70 internex 1 1 > 192.41.177.80 ios 10 8 > 192.41.177.85 cais 184 158 > 192.41.177.86 hlc 354 243 > 192.41.177.89 energis 2 2 > 192.41.177.95 delphi 3 3 > > A final note: We're open to {Additional static sources of route tables at > MAE-East; Additional static sources of route tables at {MAE-West, Pennsauken, > or the PacBell NAP}; and dynamic (i.e. the vty password so we can run > a sho ip bgp summ every so often) sources at any of the MAEs or NAPs. You will find that while improvement is possible, and may still even be fairly substantial, your figures represent an optimistic estimate. Another way of estimating what can be aggregated is by determining from how many places all of the components of an aggregate could be heard in all backup situations. In some cases it might be reasonable to drop some degree of alternate connectivity (fourth or fifth preferred paths) and allow a number of holes (specifically aggregated components). In principle this could be done algorithmically using the IRR. In practice, you need to check with some of the parties involved to make sure registered information (particialrly aut-num AS peerings) are accurate beforehand. Using the IRR you (or we) can select candidates for aggregation and then make sure the aggregation can really be asfely done. This is a little different in than you estimate in that it the viewpoint is what can we aggregate, rather than what might we see better aggregated in the future. The bgp paths at major interconnects could form a useful sanity check, making sure that AS paths do not conflict with IRR AS peering information for any candidate for aggregation. > If we get good feedback, we may automate this to run overnight and keep > a history. > > Avi Freedman > freedman@netaxs.com Thanks for the information. Curtis ps- This thread was not about ANS, but for those following NANOG activity might who may want it, here is a brief update. We have not yet deployed the code needed to generate configurations that take advantage of aggregates marked in the IRR. For a rough hint at where we are headed, see: ftp://ftp.ans.net/pub/papers/slides/nanog-sep-1995-proxy-agg.ps   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25298; 27 Nov 95 14:37 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25293; 27 Nov 95 14:37 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa25672; 27 Nov 95 14:37 EST Received: from cesium.clock.org (cesium.clock.org [17.255.4.43]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id FAA18305 for ; Tue, 28 Nov 1995 05:36:01 +1100 Received: by cesium.clock.org id <5611>; Mon, 27 Nov 1995 10:35:56 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sean Doran To: enke@mci.net Subject: Re: CIDR Aggregation Tool Cc: cidrd@iepg.org, freedman@netaxs.com Message-Id: <95Nov27.103556pst.5611@cesium.clock.org> Date: Mon, 27 Nov 1995 10:35:45 -0800 Enke - I agree absolutely with you, but there is no particular reason one couldn't do both. Andrew's work with community attributes has been very interesting, and among the various things that have been done has been setting the no-export community on more-specific prefixes. I gather that this is sometimes done by customers attached to their network, which strikes me as pretty nifty. This has easy application with respect to more-specific prefixes that have to be known by an immediate provider, but which is aggregatable at that provider's borders. Either the customer or the provider can set the attribute. So, another question is how to get PSI, JvNC, DATANET and others not to announce their more specifics to the world in the short run so they fall out of the top slots on Tony's list? Sean.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25354; 27 Nov 95 14:38 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25350; 27 Nov 95 14:38 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa25710; 27 Nov 95 14:38 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA21667; Tue, 28 Nov 1995 06:30:39 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA21635; Tue, 28 Nov 1995 06:22:55 +1100 Received: from aero.branch.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12543; Tue, 28 Nov 1995 06:22:53 +1100 (from jon@branch.com) Received: by aero.branch.com (mail) id m0tK97D-000Nj7C; Mon, 27 Nov 95 14:21 EST Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jon Zeeff Subject: Re: CIDR Aggregation Tool To: curtis@ans.net Date: Mon, 27 Nov 1995 14:21:22 -0500 (EST) Cc: freedman@netaxs.com, big-internet@munnari.oz.au, cidrd@iepg.org, nanog@merit.edu In-Reply-To: <199511271850.NAA01164@brookfield.ans.net> from "Curtis Villamizar" at Nov 27, 95 01:50:17 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 394 Precedence: bulk I wouldn't mind if aggregation was done automatically unless the route was specifically registered somewhere as being a "don't aggregate" route. In other words, let people indicate if it wasn't a mistake. > load splitting across providers (usually load split by AS path > filtering or more simply by AS path length). There is no way to tell > a mistake from this being done intentionally.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25379; 27 Nov 95 14:39 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25375; 27 Nov 95 14:39 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa25734; 27 Nov 95 14:39 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA21689; Tue, 28 Nov 1995 06:33:10 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA21632; Tue, 28 Nov 1995 06:17:05 +1100 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07030; Tue, 28 Nov 1995 06:17:02 +1100 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id OAA16293; Mon, 27 Nov 1995 14:16:49 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Avi Freedman Message-Id: <199511271916.OAA16293@netaxs.com> Subject: Re: CIDR Aggregation Tool To: curtis@ans.net Date: Mon, 27 Nov 1995 14:16:48 -0500 (EST) Cc: big-internet@munnari.oz.au, cidrd@iepg.org, nanog@merit.edu In-Reply-To: <199511271850.NAA01164@brookfield.ans.net> from "Curtis Villamizar" at Nov 27, 95 01:50:17 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1709 Precedence: bulk > Avi, > > While this is useful as a metric of the degree of aggregation, it is > not sufficient to configure aggregation. This is still useful as a > means to look at where improvement may be needed. Please don't get me > wrong in pointing out that there are limits to the applicability, this > *is* useful. I should have been much more specific. There was never any intent to suggest that this was a configuration-generator... Nor was there any intent to imply that certain providers are bad or remiss or misconfigured or underconfigured... The hope was that it might be useful as something to look at (a raw generator of aggregation-possibilities). Also, I was interested in seeing how many routes could be aggregated at one peering point (not inside a provider's network, but at one edge). For example, if the processing to compute the aggregations was low, and only aggregated entries were inserted into a cache (but the actual BGP announced more specific entries were kept in the routing table), perhaps that would help if route table and/or cache table size was/is still a problem. But it seems that the current generation of technology that is out there doesn't run into a SP-cache-size wall from either a switching-speed or memory angle. > You will find that while improvement is possible, and may still even > be fairly substantial, your figures represent an optimistic estimate. Agreed. [Suggestions re: IRR deleted for brevity.] Agreed re: the IRR as well. Next on the list is to examine the Merit tools. Sigh - my nanog notes were lost when my 200LX was stolen, but I know where to find the tools... > Thanks for the information. Thanks for the feedback. > Curtis Avi   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04895; 27 Nov 95 19:35 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04891; 27 Nov 95 19:35 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa03714; 27 Nov 95 19:35 EST Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id JAA21211 for ; Tue, 28 Nov 1995 09:46:26 +1100 Received: from zpoprp.zpo.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA09556; Mon, 27 Nov 1995 14:41:16 -0800 Received: from slp6.zpo.dec.com by zpoprp.zpo.dec.com; (5.65v3.2/1.1.8.2/26Sep95-1114AM) id AA05246; Tue, 28 Nov 1995 06:41:12 +0800 Date: Tue, 28 Nov 1995 06:41:12 +0800 Message-Id: <9511272241.AA05246@zpoprp.zpo.dec.com> X-Sender: rtan@zpoprp.zpo.dec.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: cidrd@iepg.org Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Richard Tan Subject: subscribe subscribe   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08224; 28 Nov 95 1:47 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08220; 28 Nov 95 1:47 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa03259; 28 Nov 95 1:47 EST Received: from plaza.aarnet.EDU.AU (plaza.aarnet.edu.au [139.130.23.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id QAA29599 for ; Tue, 28 Nov 1995 16:15:33 +1100 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by plaza.aarnet.EDU.AU (8.6.8/8.6.5) with ESMTP id QAA28659 for ; Tue, 28 Nov 1995 16:02:27 +1100 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.12) with ESMTP id AAA03823; Tue, 28 Nov 1995 00:00:31 -0500 Message-Id: <199511280500.AAA03823@brookfield.ans.net> To: Sean Doran cc: enke@ns.mci.net, freedman@netaxs.com, cidrd@iepg.org Reply-To: curtis@ans.net Subject: Re: CIDR Aggregation Tool In-reply-to: Your message of "Mon, 27 Nov 1995 09:18:01 PST." <95Nov27.091812pst.5606@cesium.clock.org> Date: Tue, 28 Nov 1995 00:00:30 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar In message <95Nov27.091812pst.5606@cesium.clock.org>, Sean Doran writes: > [destinations pruned to CIDRD] > > Enke - > > One nice tweak I played with for a while the last time I > had anything remotely like time to do ad hoc coding was > figuring out which ASes were essentially unnecessary with > respect to global routing. > > Curtis and Daniel will say that this requires a routing > registry, and they may be right, however, armed with various > views, one can pretty much tell that there are numbers of ASes > which could be aggregated together somewhere upstream. > > In fact, anything in our newer (and nonportable) CIDR > blocks are aggregated with respect to outbound announcements > from AS1239, so a number of holes caused by customers needing > to do BGP with us are simply never seen by the rest of the > world. > > Catching this from the outside is awkward (it requires > knowing essentially what CIDR blocks belong to whom, which > is a function mostly filled by the current address allocation > registries), but anything that can identify a large > aggregatable chunk, particularly a newer chunk, even at the > level of a neighbour at MAE-EAST is a good move, imho. > > Sean. Doing this from the outside requires an accurate map of the AS peerings and AS announcements that you should be able to get from the aut-num objects if everyone had one. Even with some of them absent, you can get subgraphs and determine some opportunities for aggregation. Whether by the IRR, or other means, aggregation that doesn't break connectivity or backup paths for anyone is welcome. btw- Could you explain how you determine what backup connectivity is available? ;-) Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08291; 28 Nov 95 1:54 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08287; 28 Nov 95 1:54 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa03323; 28 Nov 95 1:54 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA22286; Tue, 28 Nov 1995 17:32:44 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA22257; Tue, 28 Nov 1995 17:13:29 +1100 Received: from brookfield-ef0.brookfield.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id GA18883; Tue, 28 Nov 1995 17:13:19 +1100 (from curtis@brookfield.ans.net) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.12) with ESMTP id BAA04101; Tue, 28 Nov 1995 01:12:10 -0500 Message-Id: <199511280612.BAA04101@brookfield.ans.net> To: Jon Zeeff Cc: curtis@ans.net, freedman@netaxs.com, big-internet@munnari.oz.au, cidrd@iepg.org, nanog@merit.edu Reply-To: curtis@ans.net Subject: Re: CIDR Aggregation Tool In-Reply-To: Your message of "Mon, 27 Nov 1995 14:21:22 EST." Date: Tue, 28 Nov 1995 01:12:09 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Precedence: bulk In message , Jon Zeeff writes: > I wouldn't mind if aggregation was done automatically unless > the route was specifically registered somewhere as being a > "don't aggregate" route. In other words, let people indicate > if it wasn't a mistake. > > > load splitting across providers (usually load split by AS path > > filtering or more simply by AS path length). There is no way to tell > > a mistake from this being done intentionally. A glance at the IRR is all it takes to find a dual homed site and determined that even though primary connectivity is through the same path as the aggregate an alternate path goes through another path. The answer there is often to aggregate anyway and pass the dual homed exceptions as explicit component routes. Problems can arise if there is no aut-num object for the AS in question, or the object is not accurate, or the routes in question don't have their own AS and are not registered correctly. Of course, if you can't be bothered registering in the IRR correctly, you have to accept the consequences. In the context of ANS's scheme after determining that something could be aggregated we would mark the aggregate with the community ANSAGGREGATE and the components with the community ANSCOMPONENTS. The rest is (not yet deployed, and not quite completely coded) magic. The aggregate would be formed in the next config run. There is also plan to use ANSPROXYAGGR and ANSPROXYCOMP but marking other peoples route objects (the components of a proxy aggregate) with a community is a hard thing to do if not in the maintainer list for the object. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14599; 28 Nov 95 9:05 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14595; 28 Nov 95 9:05 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa09529; 28 Nov 95 9:05 EST Received: from austin.bsdi.com (austin.BSDI.COM [205.230.229.1]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id WAA05517 for ; Tue, 28 Nov 1995 22:26:15 +1100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: owner-inet-access@earth.com Received: (from daemon@localhost) by austin.bsdi.com (8.6.12/8.6.12) id FAA23335 for cidrd@iepg.org; Tue, 28 Nov 1995 05:26:06 -0600 Date: Tue, 28 Nov 1995 05:26:06 -0600 Message-Id: <199511281126.FAA23335@austin.bsdi.com> To: cidrd@iepg.org Subject: Invalid user: cidrd@iepg.org Errors-To: owner-inet-access@earth.com Originator: owner-inet-access@earth.com Precedence: bulk Posting to inet-access@earth.com is restricted to registered users. To contact the list admin send email to . If you are not a registered user then you must register before you can send email to this list. If you are a registered user then your registered email address is apparently different than the address from which you sent this message. You can update your record by sending email to : unsubscribe subscribe --- HELP FILE --------------------------------------------- HELPFILE inet-access@earth.com, the Internet Access Providers mailing list. The purpose of the list is to exchange ideas about setting up and running Internet access systems and discuss issues related to being an Internet Access Provider (IAP) or Internet Service Provider (ISP). The list is expressly *not* for users to ask questions about internet providers, they should use Usenet's alt.internet.services for that. *All* administrative requests should go to To have your email address added to the mailing list send the following to the above address in the *body* of the message: subscribe Or if you wish to subscribe an alternate email address you can use: subscribe To remove your email address from the mailing list send: unsubscribe or unsubscribe There are *NO* other list options available. Only registered members can submit messages to the list. You can access the inet-access archives via anonymous ftp to ftp.earth.com in pub/archive/inet-access (see the FAQ there). If you have some material that you would like me to archive on the server then send it to with subject ``Archive''. To contact the listadmin directly email to owner-inet-access@earth.com. ------- Forwarded Message Received: from VM.TAU.AC.IL (taunivm.tau.ac.il [132.66.32.4]) by austin.bsdi.com (8.6.12/8.6.12) with SMTP id FAA23326 for ; Tue, 28 Nov 1995 05:24:28 -0600 Message-Id: <199511281124.FAA23326@austin.bsdi.com> Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 5482; Tue, 28 Nov 95 13:22:48 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 0593; Tue, 28 Nov 1995 13:22:43 +0200 Date: Tue, 28 Nov 95 13:11:21 IST From: Hank Nussbacher Subject: CIDR FAQ To: cidrd@iepg.org, nanog@merit.edu, inet-access@EARTH.COM, iap@vma.cc.nd.edu, local-ir@vma.cc.nd.edu, local-ir@apnic.net X-Reply-To: cidrd@iepg.org MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT ------------------------------------------------------------------------ The CIDR FAQ Version 5 15 November 1995 ------------------------------------------------------------------------ The following document is a collection of Frequently Asked Questions about CIDR. This document is not meant to be a networking/routing guide and tutorial. Where appropriate pointers to other documents of a more general nature have been mentioned. Updates from a previous version are marked with a '|' in column 1. If you have any questions you would like added, please send them to the editor mentioned below: Hank Nussbacher (Tel Aviv University and IBM Israel) hank@vm.tau.ac.il or hank@ibm.net.il If you would like to "discuss" items from this FAQ please send your mail to cidrd@iepg.org This FAQ is being distributed to the following groups and lists: alt.internet.services alt.internet.access.wanted nanog@merit.edu inet-access@earth.com iap@vma.cc.nd.edu local-ir@ripe.net cidrd@iepg.org |local-ir@apnic.net To retrieve the most up-to-date version of this document: |- ftp://ftp.ibm.net.il/pub/docs/cidr.faq |- http://www.rain.net/faq/cidr.faq.html ------------------------------------------------------------------------ General questions ----------------- 1. What does CIDR stand for? CIDR stands for Classless Inter-Domain Routing and is documented in RFC1517/1518/1519/1520. CIDR is an effective method to stem the tide of IP address allocation as well as routing table overflow. Without CIDR having been implemented in 1994 & 1995, the Internet would not be functioning today. Basically, CIDR eliminates the concept of class A, B, and C networks and replaces this with a generalized "IP prefix". CIDR can be used to perform route aggregation in which a single route can cover the address space of several "old-style" network numbers and thus replace a lot of old routes. This lessens the local administrative burden of updating external routing, saves routing table space in all backbone routers and reduces route flapping (rapid changes in routes), and thus CPU load, in all backbone routers. CIDR will also allow delegation of pieces of what use d to be called "network numbers" to customers, and therefore make it possible to utilize the available address space more efficiently. See question #6 below for details on "IP prefix"s. 2. What is an ASN? ASN stands for Autonomous System Number and acts to merge many networks into a logical domain. 3. What is BGP? BGP stands for Border Gateway Protocol and is the de-facto standard for routing between Autonomous Systems in the Internet. All communications between Internet Service Providers (ISP) is handled via BGP4 which supports CIDR. 4. Why should I make the effort and convert my routing to be CIDRized? The routing tables in the Internet have been growing as fast as the Internet and the router technology specifically and computer technology in general has not been able to keep pace. In December 1990 there were 2190 routes and 2 years later there were over 8500 routes. In July 1995 there are now over 29,000 routes, which require approximately 10 MB in a router with a single peer. Routers at interconnection points (or multi-homed hosts doing full routing with many peers) receive these routes from several peers, and need several dozen megabytes of RAM (and the appropriate CPU horsepower) to handle this. A list of those routers that can handle this appears at the end of this question. Routers with 64MB of memory have the capacity for approximately 60,000 routes after which some routes will just have to be left out of the global routing tables, and the more likely ones to be left out are routes covering small pieces of address space. Without the CIDRization work that has gone on for the past 2 years the routing tables would be in excess of 65,000 routes. By CIDRizing you help the Internet reduce the routing overload as well as increasing the liklihood that in the future your routes will be carried by all ISPs. The major benefit of CIDR is to allow for continuous, uninterrupted growth of the Internet. For a significant percentage of sites connected to the Internet the value of the Internet increases with the total number of sites connected to the Internet. Therefore, taking steps needed to allow for continuous uninterrupted growth (like CIDRizing, or renumbering) is beneficial to such sites. The routers today that are available to handle the full routing table are: cisco 7000 w/ 64Mb cisco 4500 w/ 32Mb IBM ENSS and CNSS w/ 64Mb BayNetworks models AN/ASN/BLN/BCN w/ 32Mb 5. Can you give an example of a simple CIDR configuration for a cisco router? The following example creates 2 aggregates and suppresses any more specific addresses that may be contained within those aggregates. The access-list causes only those nets to be distributed as listed, and not any others that may exist in the BGP routing tables. router bgp 64100 no synchronization aggregate-address 172.16.0.0 255.248.0.0 summary-only aggregate-address 192.168.50.0 255.255.255.0 summary-only neighbor 192.168.54.2 remote-as 65000 neighbor 192.168.54.2 distribute-list 12 out default-metric 70 ! access-list 12 permit 192.168.50.0 0.0.0.255 access-list 12 permit 172.16.0.0 0.7.255.255 | Another method might be: | | router bgp 64100 | no synchronization | aggregate-address 172.16.0.0 255.248.0.0 | aggregate-address 192.168.50.0 255.255.255.0 | neighbor 192.168.54.2 remote-as 65000 | neighbor 192.168.54.2 distribute-list 102 out | default-metric 70 | ! | access-list 102 deny 172.16.0.0 0.7.255.255 255.252.0.0 0.3.255.255 | access-list 102 deny 192.168.50.0 0.0.0.255 255.255.255.128 0.0.0.127 An alternate method is via network and route statements: router bgp 64100 no synchronization network 172.16.0.0 mask 255.248.0.0 network 192.168.50.0 mask 255.255.255.0 neighbor 192.168.54.2 remote-as 65000 neighbor 192.168.54.2 default-metric 70 ip route 172.16.0.0 255.248.0.0 Null0 254 ip route 192.168.50.0 255.255.255.0 Null0 254 In this case, only those routes explicitly mentioned in "network" statements will be announced with BGP. For these routes to be announced, there has to be a corresponding route in the IP forwarding table, thus the need to create the static routes. The static routes will also serve as "pull-ups" for the route advertisements and thus prevent route flapping: these routes will always be announced with BGP by this router. Note that as long as more specific routes exist internally in your network, these will be used in preference to the static "less specific" route entries (longest prefix matching is being used). A good rule to follow is to never redistribute IGP learnt routes directly into BGP, but to rather use network or aggregate-address statements. And if you must redistribute dynamically learnt IGP routes into BGP, you MUST use filtering. The reasons for this advice are several, some of which are: 1) if your IGP is classful (e.g. RIP or IGRP) you will by default not do any route aggregation 2) if you have an internal stability problem (accidents do happen), this will be reflected as a "route flap" in the whole routing system, globally burning CPU cycles better spent on other things 3) if the IGP -> BGP transition is unrestricted, this can lead to false routing information escaping from your network (especially if you do not fully have administrative control over your IGP) 6. What do all these /16s and /24s mean in my BGP tables? This refers to the number of bits of the network part of the IP address. A former class B may appear as 172.50.0.0/16, which is the same as 256 class C's which can appear as 192.200.0.0/16. A single class C appears as 192.201.1.0/24. These "things" are often called an "IP prefix", which consists of an IP address and a mask length. The mask length specifies the number of leftmost contiguous significant bits in the corresponding IP address. Thus, an IP prefix with a prefix length of 15 (denoted /15) covers the address space of 128k IP addresses, and a /17 covers the address space of 32k IP addresses. Here is a table of the more popular CIDR blocks: # of former CIDR class C block nets ---- ---- /27 1/8 /26 1/4 /25 1/2 /24 1 /23 2 /22 4 /21 8 /20 16 /19 32 /18 64 /17 128 /16 256 = 1 former class B /15 512 /14 1024 /13 2048 In general, advertising a prefix covering less address space than a /24 prefix will probably not get into the global routing tables, and global Internet connectivity is less likely to happen. Note that for you as an administrator of an AS, it is a good idea to announce as few prefixes as possible and to utilize the address space as much as possible. | A more comprehensive table came out in October 1995 as: | | RFC1860: Variable Length Subnet Table For IPv4 | | This RFC is being revised and a new one will be out shortly. 7. Do I need to carry the full Internet routing table? When would it be necessary? What routers on the Internet carry full routing tables and how much memory is needed? No you do not need to carry the full Internet routing table. If you are single-homed, meaning you have a single connection to an ISP, then all you need to do is point a default route to the ISP and tell your ISP not to send you the full routing table. If you are multi-homed, you will want to know which nets to route via connection A and which nets to route via connection B. The easiest way to do this is to request a partial routing table from one ISP - with those nets that are closest to them, and default everything else to the other ISP. This way your routing tables need not contain the entire Internet universe but only a small subset. The closer you get to the hub or nexus of the Internet, the larger your routing tables need to be. For example, those connected to public exchange points (like the NAPs, CIX, STIX, LINX, dGIX) in general, carry full routing tables and run without a default route. 8. What is there in the Internet to stop me from making a mistake and announcing via BGP an aggregate that is larger than the nets I am in charge of? In principle there is nothing to stop you. The responsibility falls on both ends of the BGP link - you are responsible to filter what you announce and the receiving end - if it has its act together - filters also what it *thinks* it should be hearing from you so as prevent mistakes on your part. Those sites that do not work with access lists and filters and just readily accept what is sent to them are just waiting for a problem to happen. Filtering can either be done at the IP network level or at the BGP path (BGP orgin AS) level. See question 20 below for details on a tool to assist in filtering. 9. Who has to renumber with CIDR ? Sites that move from one ISP to another, and who had been allocated addresses from their original ISP's CIDR block, in all likelihood will have to return those addresses as part of the move. The reason is to keep the number of prefixes in the global routing system within the limits of current technology. | For further hints and procedures for renumbering, see the PIER | (Procedures for Internet/Enterprise Renumbering) homepage at: | | http://www.isi.edu:80/div7/pier Specific questions ------------------ 10. I have a /16 but have registered parts of it as /24s in the RADB. I now want to CIDRize. The problem is parts of the /16s are missing and are routed via a different ASN. Can you explain how more specific routes override more general ones and will I hurt my routing if I just advertise the /16 and not a bunch of /20s and /21s? There are two aspects to the answer: 1) Real (BGP) world: Given there are several AS's sharing addresses out of a /16 prefix, every AS should advertise exactly those prefixes which it is really originating. However, if there is one AS "originating" a significant majority of this address space, the concerned AS's might agree that this one and only advertises the /16 and all others their more specifics. The more specifics always take precedence over the less specific. 2) Routing registry: The registry DB, of course, should always reflect reality. If in the above example the AS's agree on the "big AS" announcing the /16, the "big AS" should document with the route-object that it's not really originating the whole aggregate by using "hole" attributes (see ripe.181, 5. The Route Object). 11. How can I redistribute our IGP routes (IGRP) so that they become aggregated when sent out via BGP? It is strongly discouraged to redistribute IGPs into BGP, because local IGP configuration errors might easily corrupt routing information of the whole Internet. If, however, you have to do it anyway, you MUST use strict distribute-lists with explicit permits (or route-maps) for redistribution. Here is an example for a Cisco configuration: router bgp 64100 aggregate-address 192.168.0.0 255.255.192.0 summary-only aggregate-address 172.16.0.0 255.254.0.0 summary-only redistribute igrp 64100 route-map origin-AS64100 ! ! or: ! redistribute igrp 64100 ! distribute-list 10 out igrp 64100 ! route-map origin-AS64100 permit 10 match ip address 10 ! access-list 10 permit 192.168.0.0 0.0.63.0 access-list 10 permit 172.16.0.0 access-list 10 permit 172.17.0.0 This example would generate one route 192.168/18 and one route 172.16/15 if any of the contained networks is in the IGP. 12. I am multihomed to three ISPs and can only CIDRize to two of them but to the third I need to still announce specific nets. What damage will this do to my AS? No damage can be done if the non-CIDR peer does not further announce your specifics to the global Internet. If your non-CIDR ISP DOES announce your specifics to the global Internet those specifics will have preference over the less specifics and therefore all traffic to you will get routed through the non-CIDR ISP. 13. I don't want to CIDRize. Can someone do proxy aggregation for me? Proxy aggregation should only be done with great care and should be avoided if you are not single-homed ! If you are single-homed ask your ISP. Others may proxy aggregate over your address range without your consent, and send your traffic over paths/links not of your choosing. Use of Routing Registries may help to identify and correct these problem areas. 14. What routers on the market today do support CIDR (classless routing)? Routers that are capable of handling CIDR are: - all Cisco routers running 10.0 or higher - all Bay Networks routers running 8.01 or higher - 3Com Netbuilder II and Netbuilder Remote Office - Telebit EMPB - Unix w/ BSD/OS 2.0 w/ gated 3.5alpha_11 + radix-fixes - IBM 2210 routers 15. How do I reach other parts of a subnetted old-style network when I have only partial routing information for that same old-style network?" There are actually three ways to solve this particular problem with Cisco's software. Which of them applies will depend on what software version is involved: o Preferred solution: turn on "ip classless" in your routers and use a default route inside your AS. The "ip classless" command prevents the existence of a single "subnet" route from blocking access via the default route to other subnets of the same old-style network. o Workaround for 9.1 or later software where the "ip classless" command is not available: install a "default network route" like this: "ip route 39.0.0.0 255.0.0.0 next-hop" along the axis your default route would normally take. o Workaround for 9.0 or older software: create a "default subnet route": "ip route 39.x.y.0 next-hop" combined with "ip default-network 39.x.y.0", otherwise as the 9.1 fix. Both of the latter solutions rely on static routes, and in the long run these will be impossible to maintain. In some topologies the use of static routes can be a problem (e.g. if you have more than one possible exit point from your AS to choose from). Supplemental information ------------------------ The following information is presented as supplemental information that is related to the CIDRization process. 16. What is the Internet Routing Registry? The IRR is a way for ASN's to publicize their own intended routing policies without having to request a change from a go-between. The RAdb which stands for the Routing Arbiter Data Base, which is part of the IRR, is part of a joint project between Merit and ISI. For full details contact: http://www.ra.net/routing.arbiter/RA/index.html. The Routing Arbiter is a project of the US National Science Foundation. As part of that project, it runs a routing registry database. That database (the RAdb) forms part of the IRR collection of databases. The RIPE database is not part of the RAdb but does participate in the IRR. At present, there are five entities that contribute to the IRR effort and more are expected. Today, all the contributing registries use the RIPE-181 database format. All IRR participants can be contacted via automail handlers that accept batch updates via email. An example of a routing update appears below: password: xxxxxxxx *rt: 138.134.0.0/16 *de: NET-IEC *or: AS378 *mb: AS378-MNT *ch: hank@aristo.tau.ac.il 950724 *so: RIPE The *rt: tag identifies the net and the routing policy is based on *or: tag. An example of a routing policy is presented below: aut-num: AS378 descr: ILAN descr: Israeli Academic and Research Network as-in: from AS1755 100 accept ANY as-in: from AS174 100 accept ANY as-in: from AS3339 100 accept AS3339 as-out: to AS1755 announce AS378 AS3339 as-out: to AS174 announce AS378 AS3339 as-out: to AS3339 announce ANY default: AS174 10 default: AS1755 20 default: AS3339 30 guardian: HANK@vm.biu.ac.il mnt-by: AS378-MNT admin-c: Hank Nussbacher tech-c: Hank Nussbacher changed: hank@vm.tau.ac.il 950627 source: RIPE For further details read over ripe-120.ps, ripe-121.ps and ripe-181.ps (via anonymous ftp from info.ripe.net/ripe/docs). |17. Are there any statistics available as to aggregation in the | Internet? | COUNTS OF RADB PREFIXES BY LENGTH - The number of Route objects | registered in the RADB, with active and withdrawn routes listed | by prefix length. Data from the current week is available from: | | ftp://ftp.ra.net/routing.arbiter/radb/reports/ | counts-by-prefix/Summarize_prefix.current | | Reports from previous weeks are available from: | | ftp://ftp.ra.net/routing.arbiter/radb/reports/ | counts-by-prefix/summarize_prefix.yymmdd | | IRR ROUTES SUMMARIZED BY PREFIX LENGTH WITH AGGREGATION - A | summary of unique prefixes registered in the IRR. Routes are | summarized by the first octet of the network number. If routes | within a prefix can be aggregated, a count is printed for each | prefix length that has a different count after aggregation. Data | from the current week is available from: | | ftp://ftp.ra.net/routing.arbiter/radb/reports/ | IRR_profile/IRR_Profile.current | | Reports from previous weeks are available from: | | ftp://ftp.ra.net/routing.arbiter/radb/reports/ | IRR_profile/IRR_Profile.yymmdd 18. How do I update the registered routing information for my ASN? You need to submit a "route" object update and perhaps an "aut-num" object update (see examples above). Route objects add new nets to your autonomous system (or you can remove nets from your autonomous system) and the Autonomous-system object describes the type of routing you wish to have. 19. Which Routing database takes precedence? RIPE? RADB? MCI? Do I have to update all of them? Each provider is allowed to select the preference order for authentic data. For example, ANS uses the following precedence: ANS, CANET, MCI, RIPE, RADB If there are two routes (with different origins) within one database, the changed date is used as a tiebreaker. Else, only database precedence is used. Thus, if the RADB entry has a more recent changed date than the RIPE, ANS will use the RIPE entry. You should only have to register in one of the IRR component databases. | There is a report which shows all routes in the RADB for a specified | AS and whether there are any duplicate routes in other IRR | registries or any aggregates which cover the route (in any of the | registries, including the RADB): | | http://www.ra.net/cgi-bin/ra/radb-duplicates.pl 20. How do I check what is registered in the IRR? The tool to use is whois. A few examples make the command self explanatory: whois -h whois.ra.net 128.228.0.0 whois -h whois.ripe.net as378 whois -h whois.canet.ca 142.77.0.0 | There is an easy Web interface to query and update the IRR: | | http://nap-roma.uni.net/cgi-bin/whois 21. Is there a tool to automatically create route filters based on IRR information? rlc is a route list compiler which is a subset of nlc/alc that allows the generation of route based filters (cisco access- lists) by extracting the nets belonging to an AS or AS MACRO from a routing database (i.e. Ripe Routing Database). In addition, it supports a limited set of functions to generate AS based filter lists. rlc is fully classless, and hence supports CIDR routes and subnets, as well as host routes. Source: ftp://dxcoms.cern.ch/pub/ripe-routing-wg Author: Jean-Michel Jouanigot, CERN |22. What other tools are available in the CIDR world? | A web version of this information can be located at: | http://www.ra.net/~ra/tools | | ------------------------ | Online Tools and Reports | ------------------------ | | IRRWeb | | This graphical interface into the Internet Routing Registry makes | it possible to use the Web to query the IRR and update RADB AS | objects, Route objects, and Maintainer objects. Users can enter | any value that can be submitted through a whois query, such as an | AS number, network IP address, or maintainer. IRRWeb then displays | the corresponding AS objects, Route objects, or Maintainer objects | from the various registries in the IRR. Authorized maintainers can | edit the objects directly; IRRWeb performs a cursory pre-check and | mails the revised object to auto-dbm@ra.net. The user then | receives e-mail from auto-dbm confirming and displaying the revised | object, or explaining why the object was rejected. | | See http://www.ra.net/cgi-bin/ra/query-radb.pl | | Source code is available at | ftp://ftp.ra.net/routing.arbiter/tools/irrweb.tar.gz | | | Route History Server | | The Route History Server provides a mechanism for tracking | the announce/withdraw history of a given prefix for the last 24 | hours. The History Server peers with the route servers at | each NAP and records all BGP updates in History Server/Route | Server peering session. | | See http://www.ra.net/cgi-bin/ra/rshist.pl | | | ----------------------- | Tools Available for FTP | ----------------------- | | RSd | | The Route Server daemon (RSd) is an enhanced version of | the GateD routing software that provides multiples views of | routing information. | The software provides a mechanism for network service provides | to off-load the computational complexity of routing policy | calculations from their routers. RSd supports configuration and | transparent passing of BGP MEDs. The software also supports | BGP route flap dampening. | | Available at ftp://ftp.ra.net/routing.arbiter/tools/rsd.tar.gz | | | Peval | A policy evaluator that inputs a RIPE-181 policy | expression, performs essential background | calculations such as symbolic evaluations and | expansions, and outputs another RIPE-181 policy | expression that is used by other tools, such as | RTConfig. | | Available as part of the RAToolSet at | ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet | | | RTConfig | A router configuration tool that can be used by | providers to generate router configs directly from | the RADB or other IRR registries. Currently in | production use for the RA Route Servers, ANSNET, and | CA*net, RTConfig is a front-end tool that uses peval | and radbserver transparently to users. | | Available as part of the RAToolSet at | ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet | | | rrc2r/rrmerge | This Cisco-to-RIPE-181 conversion package makes it possible for | users to convert Cisco router configuration files to RIPE-181 | objects that can be submitted to the Internet Routing Registry | (IRR). The Cisco access-list can be converted into an explicit set | of nets embedded in an AS object or represented as a community. | The RADBserver is queried for any missing or previously registered | information. | | Available at | ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet/rrc2r-0.2.tar.gz | | | CiscoBGP | IRR users have long recognized the need for tools that check the | IRR against routes actually propagated in the Internet. CiscoBGP | obtains and analyzes routing information from production Ciscos, | and compares the data with routes in the IRR. The software also | flags prefixes that are reserved by RFC 1597, Address Allocation | for Private Internets. | | Available as part of the MRT software distribution at | http://www.merit.edu/~mrt | | | BGPCheck | BGPCheck obtains and analyzes routing information from BGP4 | peering sessions, and compares the data with routes in the IRR. The | software also flags prefixes that are reserved by | RFC 1597, Address Allocation for Private Internets. | | Available as part of the MRT software distribution at | http://www.merit.edu/~mrt | | | PRtraceroute | The 'prtraceroute' tool is a powerful form of traceroute that | displays the Autonomous Systems that a packet traverses. | PRtraceroute was developed by the Pride project. | | A version of prtraceroute that queries the RADB is available at | ftp://ftp.ra.net/routing.arbiter/pride/prtraceroute-2.0beta2.shar.gz | | | ------------------ | Tool Announcements | ------------------ | PGP-Based Radb Authentication | Follow these steps to take advantage of the new RADB support for | PGP-based digital signatures: | | 1. Register your public key with the Routing Arbiter Service. | 2. Modify your Maintainer object to reflect your use of digital | signatures. | 3. Use PGP to sign your RADB transactions. | | For detailed instructions, see: | http://www.ra.net/routing.arbiter/RA/RADB.tools.docs/pgp.html Contributors: Christian Panigl - Vienna University, Austria Bill Manning - ISI Tony Li - Cisco Systems Havard Eidnes - SINTEF, Norway Yakov Rekhter - Cisco Systems | Craig Labovitz - Merit Network ------- End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14614; 28 Nov 95 9:05 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14607; 28 Nov 95 9:05 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa09492; 28 Nov 95 9:03 EST Received: from VM.TAU.AC.IL (taunivm.tau.ac.il [132.66.32.4]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id WAA05492 for ; Tue, 28 Nov 1995 22:24:21 +1100 Message-Id: <199511281124.WAA05492@nico.aarnet.edu.au> Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 5482; Tue, 28 Nov 95 13:22:48 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 0593; Tue, 28 Nov 1995 13:22:43 +0200 Date: Tue, 28 Nov 95 13:11:21 IST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hank Nussbacher Subject: CIDR FAQ To: cidrd@iepg.org, nanog@merit.edu, inet-access@earth.com, iap@vma.cc.nd.edu, local-ir@vma.cc.nd.edu, local-ir@apnic.net Reply-To: cidrd@aarnet.edu.au MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT ------------------------------------------------------------------------ The CIDR FAQ Version 5 15 November 1995 ------------------------------------------------------------------------ The following document is a collection of Frequently Asked Questions about CIDR. This document is not meant to be a networking/routing guide and tutorial. Where appropriate pointers to other documents of a more general nature have been mentioned. Updates from a previous version are marked with a '|' in column 1. If you have any questions you would like added, please send them to the editor mentioned below: Hank Nussbacher (Tel Aviv University and IBM Israel) hank@vm.tau.ac.il or hank@ibm.net.il If you would like to "discuss" items from this FAQ please send your mail to cidrd@iepg.org This FAQ is being distributed to the following groups and lists: alt.internet.services alt.internet.access.wanted nanog@merit.edu inet-access@earth.com iap@vma.cc.nd.edu local-ir@ripe.net cidrd@iepg.org |local-ir@apnic.net To retrieve the most up-to-date version of this document: |- ftp://ftp.ibm.net.il/pub/docs/cidr.faq |- http://www.rain.net/faq/cidr.faq.html ------------------------------------------------------------------------ General questions ----------------- 1. What does CIDR stand for? CIDR stands for Classless Inter-Domain Routing and is documented in RFC1517/1518/1519/1520. CIDR is an effective method to stem the tide of IP address allocation as well as routing table overflow. Without CIDR having been implemented in 1994 & 1995, the Internet would not be functioning today. Basically, CIDR eliminates the concept of class A, B, and C networks and replaces this with a generalized "IP prefix". CIDR can be used to perform route aggregation in which a single route can cover the address space of several "old-style" network numbers and thus replace a lot of old routes. This lessens the local administrative burden of updating external routing, saves routing table space in all backbone routers and reduces route flapping (rapid changes in routes), and thus CPU load, in all backbone routers. CIDR will also allow delegation of pieces of what use d to be called "network numbers" to customers, and therefore make it possible to utilize the available address space more efficiently. See question #6 below for details on "IP prefix"s. 2. What is an ASN? ASN stands for Autonomous System Number and acts to merge many networks into a logical domain. 3. What is BGP? BGP stands for Border Gateway Protocol and is the de-facto standard for routing between Autonomous Systems in the Internet. All communications between Internet Service Providers (ISP) is handled via BGP4 which supports CIDR. 4. Why should I make the effort and convert my routing to be CIDRized? The routing tables in the Internet have been growing as fast as the Internet and the router technology specifically and computer technology in general has not been able to keep pace. In December 1990 there were 2190 routes and 2 years later there were over 8500 routes. In July 1995 there are now over 29,000 routes, which require approximately 10 MB in a router with a single peer. Routers at interconnection points (or multi-homed hosts doing full routing with many peers) receive these routes from several peers, and need several dozen megabytes of RAM (and the appropriate CPU horsepower) to handle this. A list of those routers that can handle this appears at the end of this question. Routers with 64MB of memory have the capacity for approximately 60,000 routes after which some routes will just have to be left out of the global routing tables, and the more likely ones to be left out are routes covering small pieces of address space. Without the CIDRization work that has gone on for the past 2 years the routing tables would be in excess of 65,000 routes. By CIDRizing you help the Internet reduce the routing overload as well as increasing the liklihood that in the future your routes will be carried by all ISPs. The major benefit of CIDR is to allow for continuous, uninterrupted growth of the Internet. For a significant percentage of sites connected to the Internet the value of the Internet increases with the total number of sites connected to the Internet. Therefore, taking steps needed to allow for continuous uninterrupted growth (like CIDRizing, or renumbering) is beneficial to such sites. The routers today that are available to handle the full routing table are: cisco 7000 w/ 64Mb cisco 4500 w/ 32Mb IBM ENSS and CNSS w/ 64Mb BayNetworks models AN/ASN/BLN/BCN w/ 32Mb 5. Can you give an example of a simple CIDR configuration for a cisco router? The following example creates 2 aggregates and suppresses any more specific addresses that may be contained within those aggregates. The access-list causes only those nets to be distributed as listed, and not any others that may exist in the BGP routing tables. router bgp 64100 no synchronization aggregate-address 172.16.0.0 255.248.0.0 summary-only aggregate-address 192.168.50.0 255.255.255.0 summary-only neighbor 192.168.54.2 remote-as 65000 neighbor 192.168.54.2 distribute-list 12 out default-metric 70 ! access-list 12 permit 192.168.50.0 0.0.0.255 access-list 12 permit 172.16.0.0 0.7.255.255 | Another method might be: | | router bgp 64100 | no synchronization | aggregate-address 172.16.0.0 255.248.0.0 | aggregate-address 192.168.50.0 255.255.255.0 | neighbor 192.168.54.2 remote-as 65000 | neighbor 192.168.54.2 distribute-list 102 out | default-metric 70 | ! | access-list 102 deny 172.16.0.0 0.7.255.255 255.252.0.0 0.3.255.255 | access-list 102 deny 192.168.50.0 0.0.0.255 255.255.255.128 0.0.0.127 An alternate method is via network and route statements: router bgp 64100 no synchronization network 172.16.0.0 mask 255.248.0.0 network 192.168.50.0 mask 255.255.255.0 neighbor 192.168.54.2 remote-as 65000 neighbor 192.168.54.2 default-metric 70 ip route 172.16.0.0 255.248.0.0 Null0 254 ip route 192.168.50.0 255.255.255.0 Null0 254 In this case, only those routes explicitly mentioned in "network" statements will be announced with BGP. For these routes to be announced, there has to be a corresponding route in the IP forwarding table, thus the need to create the static routes. The static routes will also serve as "pull-ups" for the route advertisements and thus prevent route flapping: these routes will always be announced with BGP by this router. Note that as long as more specific routes exist internally in your network, these will be used in preference to the static "less specific" route entries (longest prefix matching is being used). A good rule to follow is to never redistribute IGP learnt routes directly into BGP, but to rather use network or aggregate-address statements. And if you must redistribute dynamically learnt IGP routes into BGP, you MUST use filtering. The reasons for this advice are several, some of which are: 1) if your IGP is classful (e.g. RIP or IGRP) you will by default not do any route aggregation 2) if you have an internal stability problem (accidents do happen), this will be reflected as a "route flap" in the whole routing system, globally burning CPU cycles better spent on other things 3) if the IGP -> BGP transition is unrestricted, this can lead to false routing information escaping from your network (especially if you do not fully have administrative control over your IGP) 6. What do all these /16s and /24s mean in my BGP tables? This refers to the number of bits of the network part of the IP address. A former class B may appear as 172.50.0.0/16, which is the same as 256 class C's which can appear as 192.200.0.0/16. A single class C appears as 192.201.1.0/24. These "things" are often called an "IP prefix", which consists of an IP address and a mask length. The mask length specifies the number of leftmost contiguous significant bits in the corresponding IP address. Thus, an IP prefix with a prefix length of 15 (denoted /15) covers the address space of 128k IP addresses, and a /17 covers the address space of 32k IP addresses. Here is a table of the more popular CIDR blocks: # of former CIDR class C block nets ---- ---- /27 1/8 /26 1/4 /25 1/2 /24 1 /23 2 /22 4 /21 8 /20 16 /19 32 /18 64 /17 128 /16 256 = 1 former class B /15 512 /14 1024 /13 2048 In general, advertising a prefix covering less address space than a /24 prefix will probably not get into the global routing tables, and global Internet connectivity is less likely to happen. Note that for you as an administrator of an AS, it is a good idea to announce as few prefixes as possible and to utilize the address space as much as possible. | A more comprehensive table came out in October 1995 as: | | RFC1860: Variable Length Subnet Table For IPv4 | | This RFC is being revised and a new one will be out shortly. 7. Do I need to carry the full Internet routing table? When would it be necessary? What routers on the Internet carry full routing tables and how much memory is needed? No you do not need to carry the full Internet routing table. If you are single-homed, meaning you have a single connection to an ISP, then all you need to do is point a default route to the ISP and tell your ISP not to send you the full routing table. If you are multi-homed, you will want to know which nets to route via connection A and which nets to route via connection B. The easiest way to do this is to request a partial routing table from one ISP - with those nets that are closest to them, and default everything else to the other ISP. This way your routing tables need not contain the entire Internet universe but only a small subset. The closer you get to the hub or nexus of the Internet, the larger your routing tables need to be. For example, those connected to public exchange points (like the NAPs, CIX, STIX, LINX, dGIX) in general, carry full routing tables and run without a default route. 8. What is there in the Internet to stop me from making a mistake and announcing via BGP an aggregate that is larger than the nets I am in charge of? In principle there is nothing to stop you. The responsibility falls on both ends of the BGP link - you are responsible to filter what you announce and the receiving end - if it has its act together - filters also what it *thinks* it should be hearing from you so as prevent mistakes on your part. Those sites that do not work with access lists and filters and just readily accept what is sent to them are just waiting for a problem to happen. Filtering can either be done at the IP network level or at the BGP path (BGP orgin AS) level. See question 20 below for details on a tool to assist in filtering. 9. Who has to renumber with CIDR ? Sites that move from one ISP to another, and who had been allocated addresses from their original ISP's CIDR block, in all likelihood will have to return those addresses as part of the move. The reason is to keep the number of prefixes in the global routing system within the limits of current technology. | For further hints and procedures for renumbering, see the PIER | (Procedures for Internet/Enterprise Renumbering) homepage at: | | http://www.isi.edu:80/div7/pier Specific questions ------------------ 10. I have a /16 but have registered parts of it as /24s in the RADB. I now want to CIDRize. The problem is parts of the /16s are missing and are routed via a different ASN. Can you explain how more specific routes override more general ones and will I hurt my routing if I just advertise the /16 and not a bunch of /20s and /21s? There are two aspects to the answer: 1) Real (BGP) world: Given there are several AS's sharing addresses out of a /16 prefix, every AS should advertise exactly those prefixes which it is really originating. However, if there is one AS "originating" a significant majority of this address space, the concerned AS's might agree that this one and only advertises the /16 and all others their more specifics. The more specifics always take precedence over the less specific. 2) Routing registry: The registry DB, of course, should always reflect reality. If in the above example the AS's agree on the "big AS" announcing the /16, the "big AS" should document with the route-object that it's not really originating the whole aggregate by using "hole" attributes (see ripe.181, 5. The Route Object). 11. How can I redistribute our IGP routes (IGRP) so that they become aggregated when sent out via BGP? It is strongly discouraged to redistribute IGPs into BGP, because local IGP configuration errors might easily corrupt routing information of the whole Internet. If, however, you have to do it anyway, you MUST use strict distribute-lists with explicit permits (or route-maps) for redistribution. Here is an example for a Cisco configuration: router bgp 64100 aggregate-address 192.168.0.0 255.255.192.0 summary-only aggregate-address 172.16.0.0 255.254.0.0 summary-only redistribute igrp 64100 route-map origin-AS64100 ! ! or: ! redistribute igrp 64100 ! distribute-list 10 out igrp 64100 ! route-map origin-AS64100 permit 10 match ip address 10 ! access-list 10 permit 192.168.0.0 0.0.63.0 access-list 10 permit 172.16.0.0 access-list 10 permit 172.17.0.0 This example would generate one route 192.168/18 and one route 172.16/15 if any of the contained networks is in the IGP. 12. I am multihomed to three ISPs and can only CIDRize to two of them but to the third I need to still announce specific nets. What damage will this do to my AS? No damage can be done if the non-CIDR peer does not further announce your specifics to the global Internet. If your non-CIDR ISP DOES announce your specifics to the global Internet those specifics will have preference over the less specifics and therefore all traffic to you will get routed through the non-CIDR ISP. 13. I don't want to CIDRize. Can someone do proxy aggregation for me? Proxy aggregation should only be done with great care and should be avoided if you are not single-homed ! If you are single-homed ask your ISP. Others may proxy aggregate over your address range without your consent, and send your traffic over paths/links not of your choosing. Use of Routing Registries may help to identify and correct these problem areas. 14. What routers on the market today do support CIDR (classless routing)? Routers that are capable of handling CIDR are: - all Cisco routers running 10.0 or higher - all Bay Networks routers running 8.01 or higher - 3Com Netbuilder II and Netbuilder Remote Office - Telebit EMPB - Unix w/ BSD/OS 2.0 w/ gated 3.5alpha_11 + radix-fixes - IBM 2210 routers 15. How do I reach other parts of a subnetted old-style network when I have only partial routing information for that same old-style network?" There are actually three ways to solve this particular problem with Cisco's software. Which of them applies will depend on what software version is involved: o Preferred solution: turn on "ip classless" in your routers and use a default route inside your AS. The "ip classless" command prevents the existence of a single "subnet" route from blocking access via the default route to other subnets of the same old-style network. o Workaround for 9.1 or later software where the "ip classless" command is not available: install a "default network route" like this: "ip route 39.0.0.0 255.0.0.0 next-hop" along the axis your default route would normally take. o Workaround for 9.0 or older software: create a "default subnet route": "ip route 39.x.y.0 next-hop" combined with "ip default-network 39.x.y.0", otherwise as the 9.1 fix. Both of the latter solutions rely on static routes, and in the long run these will be impossible to maintain. In some topologies the use of static routes can be a problem (e.g. if you have more than one possible exit point from your AS to choose from). Supplemental information ------------------------ The following information is presented as supplemental information that is related to the CIDRization process. 16. What is the Internet Routing Registry? The IRR is a way for ASN's to publicize their own intended routing policies without having to request a change from a go-between. The RAdb which stands for the Routing Arbiter Data Base, which is part of the IRR, is part of a joint project between Merit and ISI. For full details contact: http://www.ra.net/routing.arbiter/RA/index.html. The Routing Arbiter is a project of the US National Science Foundation. As part of that project, it runs a routing registry database. That database (the RAdb) forms part of the IRR collection of databases. The RIPE database is not part of the RAdb but does participate in the IRR. At present, there are five entities that contribute to the IRR effort and more are expected. Today, all the contributing registries use the RIPE-181 database format. All IRR participants can be contacted via automail handlers that accept batch updates via email. An example of a routing update appears below: password: xxxxxxxx *rt: 138.134.0.0/16 *de: NET-IEC *or: AS378 *mb: AS378-MNT *ch: hank@aristo.tau.ac.il 950724 *so: RIPE The *rt: tag identifies the net and the routing policy is based on *or: tag. An example of a routing policy is presented below: aut-num: AS378 descr: ILAN descr: Israeli Academic and Research Network as-in: from AS1755 100 accept ANY as-in: from AS174 100 accept ANY as-in: from AS3339 100 accept AS3339 as-out: to AS1755 announce AS378 AS3339 as-out: to AS174 announce AS378 AS3339 as-out: to AS3339 announce ANY default: AS174 10 default: AS1755 20 default: AS3339 30 guardian: HANK@vm.biu.ac.il mnt-by: AS378-MNT admin-c: Hank Nussbacher tech-c: Hank Nussbacher changed: hank@vm.tau.ac.il 950627 source: RIPE For further details read over ripe-120.ps, ripe-121.ps and ripe-181.ps (via anonymous ftp from info.ripe.net/ripe/docs). |17. Are there any statistics available as to aggregation in the | Internet? | COUNTS OF RADB PREFIXES BY LENGTH - The number of Route objects | registered in the RADB, with active and withdrawn routes listed | by prefix length. Data from the current week is available from: | | ftp://ftp.ra.net/routing.arbiter/radb/reports/ | counts-by-prefix/Summarize_prefix.current | | Reports from previous weeks are available from: | | ftp://ftp.ra.net/routing.arbiter/radb/reports/ | counts-by-prefix/summarize_prefix.yymmdd | | IRR ROUTES SUMMARIZED BY PREFIX LENGTH WITH AGGREGATION - A | summary of unique prefixes registered in the IRR. Routes are | summarized by the first octet of the network number. If routes | within a prefix can be aggregated, a count is printed for each | prefix length that has a different count after aggregation. Data | from the current week is available from: | | ftp://ftp.ra.net/routing.arbiter/radb/reports/ | IRR_profile/IRR_Profile.current | | Reports from previous weeks are available from: | | ftp://ftp.ra.net/routing.arbiter/radb/reports/ | IRR_profile/IRR_Profile.yymmdd 18. How do I update the registered routing information for my ASN? You need to submit a "route" object update and perhaps an "aut-num" object update (see examples above). Route objects add new nets to your autonomous system (or you can remove nets from your autonomous system) and the Autonomous-system object describes the type of routing you wish to have. 19. Which Routing database takes precedence? RIPE? RADB? MCI? Do I have to update all of them? Each provider is allowed to select the preference order for authentic data. For example, ANS uses the following precedence: ANS, CANET, MCI, RIPE, RADB If there are two routes (with different origins) within one database, the changed date is used as a tiebreaker. Else, only database precedence is used. Thus, if the RADB entry has a more recent changed date than the RIPE, ANS will use the RIPE entry. You should only have to register in one of the IRR component databases. | There is a report which shows all routes in the RADB for a specified | AS and whether there are any duplicate routes in other IRR | registries or any aggregates which cover the route (in any of the | registries, including the RADB): | | http://www.ra.net/cgi-bin/ra/radb-duplicates.pl 20. How do I check what is registered in the IRR? The tool to use is whois. A few examples make the command self explanatory: whois -h whois.ra.net 128.228.0.0 whois -h whois.ripe.net as378 whois -h whois.canet.ca 142.77.0.0 | There is an easy Web interface to query and update the IRR: | | http://nap-roma.uni.net/cgi-bin/whois 21. Is there a tool to automatically create route filters based on IRR information? rlc is a route list compiler which is a subset of nlc/alc that allows the generation of route based filters (cisco access- lists) by extracting the nets belonging to an AS or AS MACRO from a routing database (i.e. Ripe Routing Database). In addition, it supports a limited set of functions to generate AS based filter lists. rlc is fully classless, and hence supports CIDR routes and subnets, as well as host routes. Source: ftp://dxcoms.cern.ch/pub/ripe-routing-wg Author: Jean-Michel Jouanigot, CERN |22. What other tools are available in the CIDR world? | A web version of this information can be located at: | http://www.ra.net/~ra/tools | | ------------------------ | Online Tools and Reports | ------------------------ | | IRRWeb | | This graphical interface into the Internet Routing Registry makes | it possible to use the Web to query the IRR and update RADB AS | objects, Route objects, and Maintainer objects. Users can enter | any value that can be submitted through a whois query, such as an | AS number, network IP address, or maintainer. IRRWeb then displays | the corresponding AS objects, Route objects, or Maintainer objects | from the various registries in the IRR. Authorized maintainers can | edit the objects directly; IRRWeb performs a cursory pre-check and | mails the revised object to auto-dbm@ra.net. The user then | receives e-mail from auto-dbm confirming and displaying the revised | object, or explaining why the object was rejected. | | See http://www.ra.net/cgi-bin/ra/query-radb.pl | | Source code is available at | ftp://ftp.ra.net/routing.arbiter/tools/irrweb.tar.gz | | | Route History Server | | The Route History Server provides a mechanism for tracking | the announce/withdraw history of a given prefix for the last 24 | hours. The History Server peers with the route servers at | each NAP and records all BGP updates in History Server/Route | Server peering session. | | See http://www.ra.net/cgi-bin/ra/rshist.pl | | | ----------------------- | Tools Available for FTP | ----------------------- | | RSd | | The Route Server daemon (RSd) is an enhanced version of | the GateD routing software that provides multiples views of | routing information. | The software provides a mechanism for network service provides | to off-load the computational complexity of routing policy | calculations from their routers. RSd supports configuration and | transparent passing of BGP MEDs. The software also supports | BGP route flap dampening. | | Available at ftp://ftp.ra.net/routing.arbiter/tools/rsd.tar.gz | | | Peval | A policy evaluator that inputs a RIPE-181 policy | expression, performs essential background | calculations such as symbolic evaluations and | expansions, and outputs another RIPE-181 policy | expression that is used by other tools, such as | RTConfig. | | Available as part of the RAToolSet at | ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet | | | RTConfig | A router configuration tool that can be used by | providers to generate router configs directly from | the RADB or other IRR registries. Currently in | production use for the RA Route Servers, ANSNET, and | CA*net, RTConfig is a front-end tool that uses peval | and radbserver transparently to users. | | Available as part of the RAToolSet at | ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet | | | rrc2r/rrmerge | This Cisco-to-RIPE-181 conversion package makes it possible for | users to convert Cisco router configuration files to RIPE-181 | objects that can be submitted to the Internet Routing Registry | (IRR). The Cisco access-list can be converted into an explicit set | of nets embedded in an AS object or represented as a community. | The RADBserver is queried for any missing or previously registered | information. | | Available at | ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet/rrc2r-0.2.tar.gz | | | CiscoBGP | IRR users have long recognized the need for tools that check the | IRR against routes actually propagated in the Internet. CiscoBGP | obtains and analyzes routing information from production Ciscos, | and compares the data with routes in the IRR. The software also | flags prefixes that are reserved by RFC 1597, Address Allocation | for Private Internets. | | Available as part of the MRT software distribution at | http://www.merit.edu/~mrt | | | BGPCheck | BGPCheck obtains and analyzes routing information from BGP4 | peering sessions, and compares the data with routes in the IRR. The | software also flags prefixes that are reserved by | RFC 1597, Address Allocation for Private Internets. | | Available as part of the MRT software distribution at | http://www.merit.edu/~mrt | | | PRtraceroute | The 'prtraceroute' tool is a powerful form of traceroute that | displays the Autonomous Systems that a packet traverses. | PRtraceroute was developed by the Pride project. | | A version of prtraceroute that queries the RADB is available at | ftp://ftp.ra.net/routing.arbiter/pride/prtraceroute-2.0beta2.shar.gz | | | ------------------ | Tool Announcements | ------------------ | PGP-Based Radb Authentication | Follow these steps to take advantage of the new RADB support for | PGP-based digital signatures: | | 1. Register your public key with the Routing Arbiter Service. | 2. Modify your Maintainer object to reflect your use of digital | signatures. | 3. Use PGP to sign your RADB transactions. | | For detailed instructions, see: | http://www.ra.net/routing.arbiter/RA/RADB.tools.docs/pgp.html Contributors: Christian Panigl - Vienna University, Austria Bill Manning - ISI Tony Li - Cisco Systems Havard Eidnes - SINTEF, Norway Yakov Rekhter - Cisco Systems | Craig Labovitz - Merit Network   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18464; 28 Nov 95 11:16 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18457; 28 Nov 95 11:16 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa12490; 28 Nov 95 11:16 EST Received: from venera.isi.edu (venera.isi.edu [128.9.0.32]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id CAA07386 for ; Wed, 29 Nov 1995 02:13:38 +1100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bmanning@isi.edu Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 28 Nov 1995 07:13:18 -0800 Posted-Date: Tue, 28 Nov 1995 07:09:31 -0800 (PST) Message-Id: <199511281509.AA12732@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Tue, 28 Nov 1995 07:09:31 -0800 Subject: Time to turn off routing To: exp39@isi.edu Date: Tue, 28 Nov 1995 07:09:31 -0800 (PST) Cc: cidrd@iepg.org X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 205 With the near-term (01dec95) deadline for the termination of the net39 experiment (RFC 1797), It might be a good idea to start dropping announcements for the various prefixes of this network. --bill   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21790; 28 Nov 95 13:08 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21786; 28 Nov 95 13:08 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa15193; 28 Nov 95 13:08 EST Received: from venera.isi.edu (venera.isi.edu [128.9.0.32]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id DAA07901 for ; Wed, 29 Nov 1995 03:03:31 +1100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bmanning@isi.edu Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 28 Nov 1995 08:03:29 -0800 Posted-Date: Tue, 28 Nov 1995 07:59:46 -0800 (PST) Message-Id: <199511281559.AA12869@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Tue, 28 Nov 1995 07:59:46 -0800 Subject: Blind Men and the Elephant To: cidrd@iepg.org Date: Tue, 28 Nov 1995 07:59:46 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 384 Perhaps this would be better on one or more of the operations lists.. (I remain unconvinced that CIDRdepolyment is a protocol activity. It smells, looks and tastes like operations to me.) Anyway, Blind Men and the Elephant.... http://info.ra.net/div7/ra/stats.html has been updated. Avi's tool has been added The RA Route Server page has been updated (has flap reports!) --bill   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22599; 28 Nov 95 13:28 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22595; 28 Nov 95 13:28 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa15624; 28 Nov 95 13:28 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA23028; Wed, 29 Nov 1995 05:18:47 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA23005; Wed, 29 Nov 1995 05:10:02 +1100 Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id SA03520; Wed, 29 Nov 1995 05:09:47 +1100 (from cengiz@ISI.EDU) Received: from cat.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 28 Nov 1995 10:09:37 -0800 Date: Tue, 28 Nov 1995 10:10:00 -0800 Posted-Date: Tue, 28 Nov 1995 10:10:00 -0800 Message-Id: <199511281810.AA22074@cat.isi.edu> Received: by cat.isi.edu (5.65c/4.0.3-4) id ; Tue, 28 Nov 1995 10:10:00 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Cengiz Alaettinoglu To: curtis@ans.net Cc: Jon Zeeff , freedman@netaxs.com, big-internet@munnari.oz.au, cidrd@iepg.org, nanog@merit.edu Subject: Re: CIDR Aggregation Tool In-Reply-To: <199511280612.BAA04101@brookfield.ans.net> References: <199511280612.BAA04101@brookfield.ans.net> X-Organisation: USC / Information Sciences Institute X-Phone: +1 (310) 822 1511 x219 X-Fax: +1 (310) 823 6714 Precedence: bulk Curtis Villamizar (curtis@ans.net) on November 28: > There is also plan > to use ANSPROXYAGGR and ANSPROXYCOMP but marking other peoples route > objects (the components of a proxy aggregate) with a community is a > hard thing to do if not in the maintainer list for the object. There are three proposals to enable marking other peoples' routes in the RPS WG: one based on ISP tags, one on route macros and one on attachment objects. Once one (or more) of these schemes are accepted and implemented, this may not be a difficult problem anymore. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00270; 28 Nov 95 17:21 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00266; 28 Nov 95 17:21 EST Received: from interlock.ans.net by CNRI.Reston.VA.US id aa21384; 28 Nov 95 17:21 EST Received: by interlock.ans.net id AA04570 (InterLock SMTP Gateway 3.0 for iwg-out@ans.net); Tue, 28 Nov 1995 16:47:39 -0500 Message-Id: <199511282147.AA04570@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 16:47:39 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 16:47:39 -0500 Date: Tue, 28 Nov 1995 16:47:35 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Susan R. Harris" To: cidrd@iepg.org, bgp@ans.net Subject: New tools from the RA project Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Greetings - Just a quick note to let you know about some new tools available from the Routing Arbiter project. Comments and bug reports welcome; please send 'em to ra-team@ra.net. > A new RADB tool tells you which RADB routes in an AS are duplicated or covered by less specific routes in the IRR: http://www.ra.net/~ra/RADB.tools.docs/.reports.html > A new tool to generate Internet routing table reports for each NAP tells you (1) the maximum number of announced routes in the Route Server's routing tables, (2) the complete Internet routing table, listed by prefix and associated AS path, as seen by the NAP's Route Servers, or (3) the number of routes seen by each Route Server, listed by RS peer and origin AS. The reports in (2) from the Washington, D.C. NAP (MAE-East) have shown some interesting numbers, like 32-bit host announcements and prefixes reserved by RFC 1597 (private internet address allocation). > You can now generate NAP route flap reports by RS peer as well as by AS origin, prefix, and specific AS: http://www.ra.net/~ra/statistics/.routes.html ------------------------------------------------------------------------ Susan R. Harris, Ph.D. Merit Network, Inc. srh@merit.edu Phone: (313) 936-2100 Fax: (313) 747-3185 ------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00564; 28 Nov 95 17:32 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00560; 28 Nov 95 17:32 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa21659; 28 Nov 95 17:32 EST Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id IAA11152 for ; Wed, 29 Nov 1995 08:47:40 +1100 Received: (from srh@localhost) by home.merit.edu (8.7.1/merit-2.0) id QAA18878; Tue, 28 Nov 1995 16:47:35 -0500 (EST) Date: Tue, 28 Nov 1995 16:47:35 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Susan R. Harris" To: cidrd@iepg.org, bgp@ans.net Subject: New tools from the RA project Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Greetings - Just a quick note to let you know about some new tools available from the Routing Arbiter project. Comments and bug reports welcome; please send 'em to ra-team@ra.net. > A new RADB tool tells you which RADB routes in an AS are duplicated or covered by less specific routes in the IRR: http://www.ra.net/~ra/RADB.tools.docs/.reports.html > A new tool to generate Internet routing table reports for each NAP tells you (1) the maximum number of announced routes in the Route Server's routing tables, (2) the complete Internet routing table, listed by prefix and associated AS path, as seen by the NAP's Route Servers, or (3) the number of routes seen by each Route Server, listed by RS peer and origin AS. The reports in (2) from the Washington, D.C. NAP (MAE-East) have shown some interesting numbers, like 32-bit host announcements and prefixes reserved by RFC 1597 (private internet address allocation). > You can now generate NAP route flap reports by RS peer as well as by AS origin, prefix, and specific AS: http://www.ra.net/~ra/statistics/.routes.html ------------------------------------------------------------------------ Susan R. Harris, Ph.D. Merit Network, Inc. srh@merit.edu Phone: (313) 936-2100 Fax: (313) 747-3185 ------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03685; 28 Nov 95 19:15 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03681; 28 Nov 95 19:15 EST Received: from interlock.ans.net by CNRI.Reston.VA.US id aa23755; 28 Nov 95 19:15 EST Received: by interlock.ans.net id AA07631 (InterLock SMTP Gateway 3.0 for iwg-out@ans.net); Tue, 28 Nov 1995 19:04:54 -0500 Message-Id: <199511290004.AA07631@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 19:04:54 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 19:04:54 -0500 Date: Tue, 28 Nov 1995 19:04:49 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Susan R. Harris" To: nanog@merit.edu, cidrd@iepg.org, bgp@ans.net, db-wg@ripe.net Subject: URL mixup Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII My apologies for mixing up the URLs in this afternoon's "new RA tools" message. The tools for generating NAP routing table and route flap reports are both available at: http://www.ra.net/~ra/statistics/ --Susan Harris   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03877; 28 Nov 95 19:25 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03872; 28 Nov 95 19:25 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa23935; 28 Nov 95 19:24 EST Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id KAA12755 for ; Wed, 29 Nov 1995 10:39:55 +1100 Received: from localhost (sjr@localhost) by home.merit.edu (8.7.1/merit-2.0) with SMTP id SAA23487; Tue, 28 Nov 1995 18:39:44 -0500 (EST) Message-Id: <199511282339.SAA23487@home.merit.edu> To: cidrd@aarnet.edu.au cc: cidrd@iepg.org, nanog@merit.edu, inet-access@earth.com, iap@vma.cc.nd.edu, local-ir@vma.cc.nd.edu, local-ir@apnic.net Subject: Re: CIDR FAQ In-reply-to: Your message of Tue, 28 Nov 1995 13:11:21 +0700. <199511281124.WAA05492@nico.aarnet.edu.au> Date: Tue, 28 Nov 1995 18:39:43 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Steven J. Richardson" Hank: I'd really appreciate just getting this much message. Thanks, Steve R./Merit > Date: Tue, 28 Nov 95 13:11:21 IST > From: Hank Nussbacher > To: cidrd@IEPG.ORG, nanog@merit.edu, inet-access@earth.com, iap@vma.cc.nd.edu, local-ir@vma.cc.nd.edu, local-ir@apnic.net > > ------------------------------------------------------------------------ > The CIDR FAQ > Version 5 > 15 November 1995 > ------------------------------------------------------------------------ > The following document is a collection of Frequently Asked Questions > about CIDR. This document is not meant to be a networking/routing > guide and tutorial. Where appropriate pointers to other documents > of a more general nature have been mentioned. > > Updates from a previous version are marked with a '|' in column 1. > > If you have any questions you would like added, please send them to > the editor mentioned below: > > Hank Nussbacher (Tel Aviv University and IBM Israel) > hank@vm.tau.ac.il or hank@ibm.net.il > > If you would like to "discuss" items from this FAQ please send > your mail to cidrd@iepg.org > > This FAQ is being distributed to the following groups and lists: > alt.internet.services > alt.internet.access.wanted > nanog@merit.edu > inet-access@earth.com > iap@vma.cc.nd.edu > local-ir@ripe.net > cidrd@iepg.org > |local-ir@apnic.net > > To retrieve the most up-to-date version of this document: > |- ftp://ftp.ibm.net.il/pub/docs/cidr.faq > |- http://www.rain.net/faq/cidr.faq.html > ------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04444; 28 Nov 95 19:53 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04440; 28 Nov 95 19:53 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa24445; 28 Nov 95 19:53 EST Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id LAA13208 for ; Wed, 29 Nov 1995 11:04:56 +1100 Received: (from srh@localhost) by home.merit.edu (8.7.1/merit-2.0) id TAA25550; Tue, 28 Nov 1995 19:04:49 -0500 (EST) Date: Tue, 28 Nov 1995 19:04:49 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Susan R. Harris" To: nanog@merit.edu, cidrd@iepg.org, bgp@ans.net, db-wg@ripe.net Subject: URL mixup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII My apologies for mixing up the URLs in this afternoon's "new RA tools" message. The tools for generating NAP routing table and route flap reports are both available at: http://www.ra.net/~ra/statistics/ --Susan Harris   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10284; 29 Nov 95 5:09 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10280; 29 Nov 95 5:09 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa05725; 29 Nov 95 5:09 EST Received: from ncc.ripe.net (ncc.ripe.net [193.0.0.129]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id UAA25225 for ; Wed, 29 Nov 1995 20:18:17 +1100 Received: from reif.ripe.net by ncc.ripe.net with SMTP id AA20894 (5.65a/NCC-2.30); Wed, 29 Nov 1995 10:17:23 +0100 Message-Id: <9511290917.AA20894@ncc.ripe.net> To: Enke Chen Cc: Sean Doran , cidrd@iepg.org Subject: CIDR Aggregation Tool In-Reply-To: Your message of Mon, 27 Nov 1995 12:43:38 EST. <199511271743.MAA27589@clone3.Reston.mci.net> References: <199511271743.MAA27589@clone3.Reston.mci.net> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Daniel Karrenberg X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Date: Wed, 29 Nov 1995 10:17:16 +0100 X-Orig-Sender: Daniel.Karrenberg@ripe.net > Enke Chen writes: > Sean, > I can see that aggregation at transit provider level is > useful, but it is dangerous and could easily cause > connectivity problems if not done with coordination. And *that coordination* (Sean) is where a routing registry is extremely useful. Sorry, just couldn't resist. Daniel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab22835; 29 Nov 95 13:31 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22816; 29 Nov 95 13:31 EST Received: from [128.250.22.5] by CNRI.Reston.VA.US id aa16564; 29 Nov 95 13:31 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA24329; Thu, 30 Nov 1995 05:09:31 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA24287; Thu, 30 Nov 1995 04:33:28 +1100 Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id RA04716; Thu, 30 Nov 1995 04:33:25 +1100 (from cengiz@ISI.EDU) Received: from cat.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 29 Nov 1995 09:33:14 -0800 Date: Wed, 29 Nov 1995 09:33:33 -0800 Posted-Date: Wed, 29 Nov 1995 09:33:33 -0800 Message-Id: <199511291733.AA24758@cat.isi.edu> Received: by cat.isi.edu (5.65c/4.0.3-4) id ; Wed, 29 Nov 1995 09:33:33 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Cengiz Alaettinoglu To: curtis@ans.net Cc: Avi Freedman , big-internet@munnari.oz.au, cidrd@iepg.org, nanog@merit.edu Subject: Re: CIDR Aggregation Tool In-Reply-To: <199511271850.NAA01164@brookfield.ans.net> References: <199511270400.XAA05234@netaxs.com> <199511271850.NAA01164@brookfield.ans.net> X-Organisation: USC / Information Sciences Institute X-Phone: +1 (310) 822 1511 x219 X-Fax: +1 (310) 823 6714 Precedence: bulk Curtis Villamizar (curtis@ans.net) on November 27: > [lots deleted] > Another way of estimating what can be aggregated is by determining > from how many places all of the components of an aggregate could be > heard in all backup situations. In some cases it might be reasonable > to drop some degree of alternate connectivity (fourth or fifth > preferred paths) and allow a number of holes (specifically aggregated > components). In principle this could be done algorithmically using > the IRR. In practice, you need to check with some of the parties > involved to make sure registered information (particialrly aut-num AS > peerings) are accurate beforehand. > > Using the IRR you (or we) can select candidates for aggregation and > then make sure the aggregation can really be asfely done. This is a > little different in than you estimate in that it the viewpoint is what > can we aggregate, rather than what might we see better aggregated in > the future. The bgp paths at major interconnects could form a useful > sanity check, making sure that AS paths do not conflict with IRR AS > peering information for any candidate for aggregation. > [lots deleted] Actually we are working on such a tool, that we call CIDR assistant. A pre-alpha release of this tool will be available before/during the IETF, and there will be a discussion of this tool in the RPS wg. This tool considers the topology and the policies registered in the IRR before suggesting potential aggregations. The amount of policy/topology that is considered is configurable. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01896; 29 Nov 95 18:22 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01892; 29 Nov 95 18:22 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa05608; 29 Nov 95 18:22 EST Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id JAA02427 for ; Thu, 30 Nov 1995 09:38:13 +1100 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id OAA17659; Wed, 29 Nov 1995 14:37:41 -0800 Date: Wed, 29 Nov 1995 14:37:41 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199511292237.OAA17659@greatdane.cisco.com> To: cidrd@iepg.org Subject: Hum on draft-ietf-cidrd-addr-ownership-04.txt Folks, The hum on "Implications of Various Address Allocation Policies for Internet Routing" (aka Address Ownership) is now complete. No negative hums (coughs?) were received. "Brian Carpenter CERN-CN" Barry Raveendran Greene Dave Siegel Ed Kern Paul Vixie Tony Li Yakov Rekhter asp@uunet.uu.net (Andrew Partan) randy@psg.com (Randy Bush) If your hum was incorrectly recorded, please contact me by 17:00 PST, 12/1/95. +1 408 526 8186 At that time, (barring substantial outcry), we will ask that the document move to become a BCP. Thanks, Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03632; 29 Nov 95 19:42 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03627; 29 Nov 95 19:42 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa07107; 29 Nov 95 19:42 EST Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.37.150]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id KAA04141 for ; Thu, 30 Nov 1995 10:56:33 +1100 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA17835 Thu, 30 Nov 1995 10:56:28 +1100 (from kre@cs.mu.OZ.AU) To: Tony Li Cc: cidrd@iepg.org Subject: Re: Hum on draft-ietf-cidrd-addr-ownership-04.txt In-Reply-To: Your message of "Wed, 29 Nov 1995 14:37:41 -0800." <199511292237.OAA17659@greatdane.cisco.com> Date: Thu, 30 Nov 1995 10:56:40 +1100 Message-Id: <841.817689400@cs.mu.OZ.AU> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Elz Given that the IETF is next week, and document movement, incl address ownership is on the (current) tentative agenda for the cidrd wg meeting, would it not be possible to defer making a decision on what to do with this doc until after the WG meeting? kre   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03726; 29 Nov 95 19:45 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03722; 29 Nov 95 19:45 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa07207; 29 Nov 95 19:45 EST Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.37.150]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id LAA04215 for ; Thu, 30 Nov 1995 11:01:14 +1100 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA18154 Thu, 30 Nov 1995 11:01:09 +1100 (from kre@cs.mu.OZ.AU) To: Tony Li Cc: cidrd@iepg.org Subject: Re: Hum on draft-ietf-cidrd-addr-ownership-04.txt In-Reply-To: Your message of "Wed, 29 Nov 1995 15:58:18 -0800." <199511292358.PAA23365@greatdane.cisco.com> Date: Thu, 30 Nov 1995 11:01:21 +1100 Message-Id: <851.817689681@cs.mu.OZ.AU> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Elz Date: Wed, 29 Nov 1995 15:58:18 -0800 From: Tony Li Message-ID: <199511292358.PAA23365@greatdane.cisco.com> Yes, I intentionally wanted to finish this BEFORE IETF so that meeting could be productive and not Yet Another Reiteration. Why is it then on the agenda? kre   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03841; 29 Nov 95 19:49 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03835; 29 Nov 95 19:49 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa07286; 29 Nov 95 19:49 EST Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id KAA04168 for ; Thu, 30 Nov 1995 10:58:26 +1100 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id PAA23365; Wed, 29 Nov 1995 15:58:18 -0800 Date: Wed, 29 Nov 1995 15:58:18 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199511292358.PAA23365@greatdane.cisco.com> To: kre@cs.mu.oz.au Cc: cidrd@iepg.org In-Reply-To: <841.817689400@cs.mu.OZ.AU> (message from Robert Elz on Thu, 30 Nov 1995 10:56:40 +1100) Subject: Re: Hum on draft-ietf-cidrd-addr-ownership-04.txt Given that the IETF is next week, and document movement, incl address ownership is on the (current) tentative agenda for the cidrd wg meeting, would it not be possible to defer making a decision on what to do with this doc until after the WG meeting? The decision has already been made. That's the purpose of the hum. Yes, I intentionally wanted to finish this BEFORE IETF so that meeting could be productive and not Yet Another Reiteration. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04722; 29 Nov 95 20:30 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04718; 29 Nov 95 20:30 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa08112; 29 Nov 95 20:30 EST Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id LAA04908 for ; Thu, 30 Nov 1995 11:37:21 +1100 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id QAA26336; Wed, 29 Nov 1995 16:37:06 -0800 Date: Wed, 29 Nov 1995 16:37:06 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199511300037.QAA26336@greatdane.cisco.com> To: kre@cs.mu.oz.au Cc: cidrd@iepg.org In-Reply-To: <851.817689681@cs.mu.OZ.AU> (message from Robert Elz on Thu, 30 Nov 1995 11:01:21 +1100) Subject: Re: Hum on draft-ietf-cidrd-addr-ownership-04.txt Yes, I intentionally wanted to finish this BEFORE IETF so that meeting could be productive and not Yet Another Reiteration. Why is it then on the agenda? Because, along with our other completed document actions, I don't want to forget to mention it. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05529; 29 Nov 95 21:15 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05525; 29 Nov 95 21:15 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa09050; 29 Nov 95 21:15 EST Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id MAA05875 for ; Thu, 30 Nov 1995 12:23:48 +1100 Received: by rip.psg.com (Smail3.1.29.1 #1) id m0tKxil-000801C; Wed, 29 Nov 95 17:23 PST Message-Id: Date: Wed, 29 Nov 95 17:23 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Randy Bush To: Robert Elz Cc: cidrd@iepg.org Subject: Re: Hum on draft-ietf-cidrd-addr-ownership-04.txt References: <199511292237.OAA17659@greatdane.cisco.com> <841.817689400@cs.mu.OZ.AU> > Given that the IETF is next week, and document movement, incl > address ownership is on the (current) tentative agenda for the > cidrd wg meeting, would it not be possible to defer making a > decision on what to do with this doc until after the WG meeting? While possible, is it desirable? With no nays, one might like to close this page and move forward beyone it in Dallas. randy