From owner-Big-Internet@murtoa.cs.mu.OZ.AU Mon Dec 18 10:20:57 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id XA04906; Mon, 18 Dec 2000 10:20:57 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBHLMbG27949; Mon, 18 Dec 2000 08:22:37 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBHLMZ827946 for ; Mon, 18 Dec 2000 08:22:35 +1100 (EST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id VA04875; Mon, 18 Dec 2000 08:22:06 +1100 (from Big-Internet-Request@munnari.OZ.AU) From: Robert Elz To: Big-Internet@munnari.OZ.AU Subject: Admin: Just flushing bad addresses from the list Date: Mon, 18 Dec 2000 08:22:06 +1100 Message-Id: <1864.977088126@mundamutti.cs.mu.OZ.AU> Precedence: bulk Apparently there is a suggestion to revive the Big-Internet list (which has been inactive since May 97). This message is just intended to cause lots of bounce messages from all the addresses on the list that have gone bad in the past 3 and a half years. If you're no longer interested in B-I messages, you can reply to this message (or simply send a message to Big-Internet-Request@munnari.oz.au) and ask to be deleted - nothing has changed since this list was set up, it is still human maintained, so sending list server type messages like "help" will usually just get you a silly reply (or no reply). On the other hand, obvious subscribe or unsuscribe messages will get acted upon. If this message gets forwarded to you via some old address, and you want your entry on the list updated, also just send mail - there's no need to go through an unsubscribe/subscribe dance, just "change my address on the list to ..." should work. kre From owner-Big-Internet@murtoa.cs.mu.OZ.AU Mon Dec 18 22:20:31 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id LA13211; Mon, 18 Dec 2000 22:20:31 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBIBIPG28451 for deliver-b-i-au; Mon, 18 Dec 2000 22:18:25 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBIBIMS28448 for ; Mon, 18 Dec 2000 22:18:22 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id FA09427; Mon, 18 Dec 2000 16:45:59 +1100 (from jdd@vbc.net) Received: from matthew.uk1.vbc.net (matthew.uk1.vbc.net [194.207.2.14]) by mumnunah.cs.mu.OZ.AU with ESMTP id QAA13739; Mon, 18 Dec 2000 16:45:52 +1100 (EST) Received: from localhost (jdd@localhost) by matthew.uk1.vbc.net (8.9.3/8.9.3) with ESMTP id FAA38099; Mon, 18 Dec 2000 05:43:17 GMT X-Authentication-Warning: matthew.uk1.vbc.net: jdd owned process doing -bs Date: Mon, 18 Dec 2000 05:43:17 +0000 (GMT) From: Jim Dixon X-Sender: jdd@matthew.uk1.vbc.net To: Robert Elz Cc: Big-Internet@munnari.OZ.AU Subject: Re: Admin: Just flushing bad addresses from the list In-Reply-To: <1864.977088126@mundamutti.cs.mu.OZ.AU> Message-Id: X-Ncc-Regid: uk.vbcnet Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 18 Dec 2000, Robert Elz wrote: > Apparently there is a suggestion to revive the Big-Internet list > (which has been inactive since May 97). > > This message is just intended to cause lots of bounce messages > from all the addresses on the list that have gone bad in the past > 3 and a half years. May I suggest that you send the list a reminder of what it is intended to be used for? -- Jim Dixon VBCnet GB Ltd http://www.vbc.net tel +44 117 929 1316 fax +44 117 927 2015 From owner-Big-Internet@murtoa.cs.mu.OZ.AU Mon Dec 18 22:51:51 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id LA13848; Mon, 18 Dec 2000 22:51:51 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBIBoJ528498 for deliver-b-i-au; Mon, 18 Dec 2000 22:50:19 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBIBoGG28494 for ; Mon, 18 Dec 2000 22:50:16 +1100 (EST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id LA14510; Mon, 18 Dec 2000 22:49:37 +1100 (from Big-Internet-Request@munnari.OZ.AU) From: Robert Elz To: Jim Dixon Cc: Big-Internet@munnari.OZ.AU Subject: Re: Admin: Just flushing bad addresses from the list In-Reply-To: Your message of "Mon, 18 Dec 2000 05:43:17 -0000." Date: Mon, 18 Dec 2000 22:49:36 +1100 Message-Id: <7412.977140176@mundamutti.cs.mu.OZ.AU> Precedence: bulk Date: Mon, 18 Dec 2000 05:43:17 +0000 (GMT) From: Jim Dixon Message-ID: | May I suggest that you send the list a reminder of what it is | intended to be used for? OK... Originally, B-I was the place where the growth of the internet was discussed - and especially the limitations imposed by the IP architecture. It came from a request from Noel Chiappa to move such discussions away from the main IETF list, back in mid 1991. It was the place where various projections of internet growth, stats on that, and some early theories were thrashed around and argued, along with early suggestions on what could be done to overcome the problems. It was also used (a little) as the public discussion forum for the ROAD group - and a non-aligned list where the various contenders for IPng were discussed and compared. Discussions mostly dropped off after the selection of the IPng protocol, though thrings dragged on a bit for another couple of years. I am not sure for what intent the list is (maybe) to be revived (it has been disabled now for years) - though something along the same lines I suspect. Since this list has been disabled, the system I use to process mailing lists has been changed, and this list had never been tested - its anti-spam is also not all that great (you all saw no spam because the list has been disabled, nothing was being distributed). Until I get all that fixed (or a least improved), and verified working, there are likely to be delays in forwarding messages to the list. Of course, if it turns out that the list isn't needed again after all, it can just return to being dormant. Archives of the list remain where they have always been ftp://munnari.oz.au/big-internet/list-archive/ with monthly files named by the month they cover (as in 1996-09-Sep) with all the archives up to (and including) 1995 compressed (.Z). The current month's archive is always found in ftp://munnari.oz.au/big-internet/list-archive/current rather than in a file with a date in its name. kre From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 19 09:12:31 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA23763; Tue, 19 Dec 2000 09:12:31 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: from localhost (localhost [[UNIX: localhost]]) by murtoa.cs.mu.OZ.AU id eBIMAZF29995 for deliver-b-i-au; Tue, 19 Dec 2000 09:10:35 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBIMAWX29992 for ; Tue, 19 Dec 2000 09:10:32 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id SA21790; Tue, 19 Dec 2000 05:42:16 +1100 (from gih@telstra.net) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by mumnunah.cs.mu.OZ.AU with ESMTP id FAA21499; Tue, 19 Dec 2000 05:42:14 +1100 (EST) Received: from tecra.telstra.net (gunk.telstra.net [203.10.60.2]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id FAA28463; Tue, 19 Dec 2000 05:39:42 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001219051657.00ac0780@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Dec 2000 05:20:17 +1100 To: Robert Elz From: Geoff Huston Subject: Re: Admin: Just flushing bad addresses from the list Cc: Jim Dixon , Big-Internet@munnari.OZ.AU In-Reply-To: <7412.977140176@mundamutti.cs.mu.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk > > | May I suggest that you send the list a reminder of what it is > | intended to be used for? > >OK... > >Originally, B-I was the place where the growth of the internet was >discussed - and especially the limitations imposed by the IP architecture. >It came from a request from Noel Chiappa to move such discussions away >from the main IETF list, back in mid 1991. The revival of this list was suggested a couple of days ago to discuss issues of scaling in the Internet. One of the concerns at present is an accelerated growth trend in the BGP table size (www.telstra.net/ops/bgp), and it was suggested that this list be used to discuss the characteristics of this growth and the characteristics of routing systems that can operate efficiently in such large environments. Or at least that's my understanding From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 19 10:30:33 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id XA24405; Tue, 19 Dec 2000 10:30:33 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBINSt800294 for deliver-b-i-au; Tue, 19 Dec 2000 10:28:55 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBINSoE00291 for ; Tue, 19 Dec 2000 10:28:51 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id XA24441; Tue, 19 Dec 2000 10:21:01 +1100 (from brian@hursley.ibm.com) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by mumnunah.cs.mu.OZ.AU with ESMTP id KAA24065; Tue, 19 Dec 2000 10:20:55 +1100 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA23858; Mon, 18 Dec 2000 15:13:48 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA20784; Mon, 18 Dec 2000 15:18:14 -0800 Message-Id: <3A3E9AE5.DC006C42@hursley.ibm.com> Date: Mon, 18 Dec 2000 17:16:53 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr Mime-Version: 1.0 To: Geoff Huston Cc: Robert Elz , Jim Dixon , Big-Internet@munnari.OZ.AU Subject: Re: Admin: Just flushing bad addresses from the list References: <4.3.2.7.2.20001219051657.00ac0780@jumble.telstra.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Plus a realistic assessment of IPv4 address space usage Brian Geoff Huston wrote: > > > > > | May I suggest that you send the list a reminder of what it is > > | intended to be used for? > > > >OK... > > > >Originally, B-I was the place where the growth of the internet was > >discussed - and especially the limitations imposed by the IP architecture. > >It came from a request from Noel Chiappa to move such discussions away > >from the main IETF list, back in mid 1991. > > The revival of this list was suggested a couple of days ago to discuss > issues of scaling in the Internet. One of the concerns at present is an > accelerated growth trend in the BGP table size (www.telstra.net/ops/bgp), > and it was suggested that this list be used to discuss the characteristics > of this growth and the characteristics of routing systems that can operate > efficiently in such large environments. > > Or at least that's my understanding From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 19 10:40:24 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id XA25424; Tue, 19 Dec 2000 10:40:24 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBINcwN00328 for deliver-b-i-au; Tue, 19 Dec 2000 10:38:58 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBINcsq00325 for ; Tue, 19 Dec 2000 10:38:54 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id XA25297; Tue, 19 Dec 2000 10:31:53 +1100 (from gih@telstra.net) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by mumnunah.cs.mu.OZ.AU with ESMTP id KAA24194 for ; Tue, 19 Dec 2000 10:31:52 +1100 (EST) Received: from tecra.telstra.net (rsdhcp4.telstra.net [203.50.0.196]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id KAA34075; Tue, 19 Dec 2000 10:29:15 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001219102316.00aae570@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Dec 2000 10:29:22 +1100 To: Brian E Carpenter From: Geoff Huston Subject: Re: Admin: Just flushing bad addresses from the list Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <3A3E9AE5.DC006C42@hursley.ibm.com> References: <4.3.2.7.2.20001219051657.00ac0780@jumble.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk At 12/18/00 05:16 PM -0600, Brian E Carpenter wrote: >Plus a realistic assessment of IPv4 address space usage Speaking of which I've just done a best fit exponential growth model against address usage data in the routing tables. After correcting for the flapping /8's I get a decent fit with daily growth of 0.0194% - extrapolating that blindly forward gets to 4.3B in April 2020. Yes, I know this is a very unsophisticated project model, but is does say to me that address consumption is not an immediate conflagration in terms of burning issues - unless of course we get an address eater application/device fielded out there. From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 19 11:11:16 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id AA08887; Tue, 19 Dec 2000 11:11:16 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: from localhost (localhost [[UNIX: localhost]]) by murtoa.cs.mu.OZ.AU id eBJ09lF00373 for deliver-b-i-au; Tue, 19 Dec 2000 11:09:47 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJ09h200370 for ; Tue, 19 Dec 2000 11:09:43 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id AA25368; Tue, 19 Dec 2000 11:05:30 +1100 (from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mumnunah.cs.mu.OZ.AU with ESMTP id LAA24642; Tue, 19 Dec 2000 11:05:26 +1100 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 148AEt-0000of-00; Mon, 18 Dec 2000 16:02:43 -0800 From: Randy Bush Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brian E Carpenter Cc: Geoff Huston , Robert Elz , Jim Dixon , Big-Internet@munnari.OZ.AU Subject: Re: Admin: Just flushing bad addresses from the list References: <4.3.2.7.2.20001219051657.00ac0780@jumble.telstra.net> <3A3E9AE5.DC006C42@hursley.ibm.com> Message-Id: Date: Mon, 18 Dec 2000 16:02:43 -0800 Precedence: bulk > Plus a realistic assessment of IPv4 address space usage i suspect that different folk's versions of 'realistic' are dissimilar. randy From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 19 13:17:12 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id CA27493; Tue, 19 Dec 2000 13:17:12 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: from localhost (localhost [[UNIX: localhost]]) by murtoa.cs.mu.OZ.AU id eBJ2FcI00464 for deliver-b-i-au; Tue, 19 Dec 2000 13:15:38 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJ2FXU00459 for ; Tue, 19 Dec 2000 13:15:33 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id BA26026; Tue, 19 Dec 2000 12:12:43 +1100 (from woody@zocalo.net) Received: from smtp1.zocalo.net (smtp1.zocalo.net [157.22.1.67]) by mumnunah.cs.mu.OZ.AU with ESMTP id MAA25749 for ; Tue, 19 Dec 2000 12:12:36 +1100 (EST) Received: from secure (secure [157.22.1.13]) by smtp1.zocalo.net (8.9.1/8.9.1) with SMTP id RAA08113; Mon, 18 Dec 2000 17:09:09 -0800 (PST) Date: Mon, 18 Dec 2000 17:07:31 -0800 (PST) From: Bill Woodcock X-Sender: woody@secure To: Geoff Huston Cc: Brian E Carpenter , Big-Internet@munnari.OZ.AU Subject: Re: Admin: Just flushing bad addresses from the list In-Reply-To: <4.3.2.7.2.20001219102316.00aae570@jumble.telstra.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > After correcting for the flapping /8's I get a decent fit with > daily growth of 0.0194% - extrapolating that blindly forward > gets to 4.3B in April 2020. My recollection is that people have been saying "about 2020" ever since the growth curve re-stabilized after CIDR deployment. Which is interesting, since it seems like the curve has changed several times since then. -Bill From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 19 13:17:12 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id CA27512; Tue, 19 Dec 2000 13:17:12 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJ2Ffh00469 for deliver-b-i-au; Tue, 19 Dec 2000 13:15:41 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJ2FaU00462 for ; Tue, 19 Dec 2000 13:15:36 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id BA26565; Tue, 19 Dec 2000 12:20:48 +1100 (from fkastenholz@unispherenetworks.com) Received: from shultz.argon.com (shultz.argon.com [208.234.161.2]) by mumnunah.cs.mu.OZ.AU with ESMTP id MAA25847 for ; Tue, 19 Dec 2000 12:20:43 +1100 (EST) Received: from fkastenholzpc.unispherenetworks.com (alpha.tunnel.argon.com [10.254.0.2]) by shultz.argon.com (8.10.0/8.10.0) with ESMTP id eBJ1Hw110914; Mon, 18 Dec 2000 20:17:59 -0500 (EST) Message-Id: <5.0.0.25.2.20001218202822.00a754f0@schultz.argon.com> X-Sender: kasten@schultz.argon.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 18 Dec 2000 20:29:55 -0500 To: Geoff Huston , Brian E Carpenter From: Frank Kastenholz Subject: Re: Admin: Just flushing bad addresses from the list Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <4.3.2.7.2.20001219102316.00aae570@jumble.telstra.net> References: <3A3E9AE5.DC006C42@hursley.ibm.com> <4.3.2.7.2.20001219051657.00ac0780@jumble.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Geoff If I recall correctly, it's the size of the BGP tables that is causing the current agita... All one needs to do is look at your graph to run screaming for the Valium (or to buy stock in SRAM companies...) Frank Kastenholz At 10:29 AM 12/19/00 +1100, Geoff Huston wrote: >At 12/18/00 05:16 PM -0600, Brian E Carpenter wrote: >>Plus a realistic assessment of IPv4 address space usage > >Speaking of which I've just done a best fit exponential growth >model against address usage data in the routing tables. > >After correcting for the flapping /8's I get a decent fit with >daily growth of 0.0194% - extrapolating that blindly forward >gets to 4.3B in April 2020. > >Yes, I know this is a very unsophisticated project model, >but is does say to me that address consumption is not an immediate >conflagration in terms of burning issues - unless of >course we get an address eater application/device >fielded out there. > > > > From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 19 14:36:35 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id DA28909; Tue, 19 Dec 2000 14:36:35 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJ3Z1H00551 for deliver-b-i-au; Tue, 19 Dec 2000 14:35:01 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJ3YgG00546 for ; Tue, 19 Dec 2000 14:34:43 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id DA28602; Tue, 19 Dec 2000 14:28:07 +1100 (from gih@telstra.net) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by mumnunah.cs.mu.OZ.AU with ESMTP id OAA27351 for ; Tue, 19 Dec 2000 14:27:54 +1100 (EST) Received: from tecra.telstra.net (rsdhcp4.telstra.net [203.50.0.196]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id OAA39500; Tue, 19 Dec 2000 14:24:39 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001219141639.00ab3960@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Dec 2000 14:24:10 +1100 To: Bill Woodcock From: Geoff Huston Subject: Re: Admin: Just flushing bad addresses from the list Cc: Big-Internet@munnari.OZ.AU In-Reply-To: References: <4.3.2.7.2.20001219102316.00aae570@jumble.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk My 2020 is based on just 1 years worth of watching the BGP table. I know that about 50% of the IPv4 space has been allocated or assigned but only 24% is actually routers. I arrived at 2020 by taking the 12 months of data of the address space spanned by the routing table (www.telstra.net/ops/bgp/bgp-total-space.html) and then filtering out the /8 flaps to get a decent set of data, and then forward extrapolating off that using an exponential best fit. The April 2020 date is when this forward extrapolation hits the 2 ** 32 number. Frankly its not a very good projection, but the essential difference between this and the earlier ALE work is that it tracks what gets routed, not what gets allocated. Now there are various points of view as to which is the 'better' data to track, but the essential message is that the deployment environment will need to alter a fair deal from current practices to change the overall picture of address usage. At 12/18/00 05:07 PM -0800, Bill Woodcock wrote: > > After correcting for the flapping /8's I get a decent fit with > > daily growth of 0.0194% - extrapolating that blindly forward > > gets to 4.3B in April 2020. > >My recollection is that people have been saying "about 2020" ever since >the growth curve re-stabilized after CIDR deployment. Which is >interesting, since it seems like the curve has changed several times since >then. > > -Bill From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 19 14:37:26 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id DA28852; Tue, 19 Dec 2000 14:37:26 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: from localhost (localhost [[UNIX: localhost]]) by murtoa.cs.mu.OZ.AU id eBJ3a2m00556 for deliver-b-i-au; Tue, 19 Dec 2000 14:36:02 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJ3ZXG00553 for ; Tue, 19 Dec 2000 14:35:33 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id DA28057; Tue, 19 Dec 2000 14:18:36 +1100 (from gih@telstra.net) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by mumnunah.cs.mu.OZ.AU with ESMTP id OAA27222 for ; Tue, 19 Dec 2000 14:18:32 +1100 (EST) Received: from tecra.telstra.net (rsdhcp4.telstra.net [203.50.0.196]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id OAA39367; Tue, 19 Dec 2000 14:15:54 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001219141411.00acb750@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Dec 2000 14:15:48 +1100 To: Frank Kastenholz From: Geoff Huston Subject: Addresses or routing... Cc: Brian E Carpenter , Big-Internet@munnari.OZ.AU In-Reply-To: <5.0.0.25.2.20001218202822.00a754f0@schultz.argon.com> References: <4.3.2.7.2.20001219102316.00aae570@jumble.telstra.net> <3A3E9AE5.DC006C42@hursley.ibm.com> <4.3.2.7.2.20001219051657.00ac0780@jumble.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk That's right - the address issues are, today, not really a pressing issue - but the routing table and the underlying shifts in the use of the routing table is cause for concern. At 12/18/00 08:29 PM -0500, Frank Kastenholz wrote: >Geoff > >If I recall correctly, it's the size of the BGP >tables that is causing the current agita... All one >needs to do is look at your graph to run screaming >for the Valium (or to buy stock in SRAM companies...) From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 19 15:35:15 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id EA28950; Tue, 19 Dec 2000 15:35:15 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJ4XjJ00653 for deliver-b-i-au; Tue, 19 Dec 2000 15:33:45 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJ4Xgx00648 for ; Tue, 19 Dec 2000 15:33:42 +1100 (EST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id EA29191; Tue, 19 Dec 2000 15:08:27 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Geoff Huston Cc: Big-Internet@munnari.OZ.AU Subject: Re: Addresses or routing... In-Reply-To: Your message of "Tue, 19 Dec 2000 14:15:48 +1100." <4.3.2.7.2.20001219141411.00acb750@jumble.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Dec 2000 15:08:21 +1100 Message-Id: <20207.977198901@mundamutti.cs.mu.OZ.AU> Precedence: bulk Date: Tue, 19 Dec 2000 14:15:48 +1100 From: Geoff Huston Message-ID: <4.3.2.7.2.20001219141411.00acb750@jumble.telstra.net> | That's right - the address issues are, today, not | really a pressing issue If you're a backbone type ISP, and your concern is managing the routers in the backbone, that's probably true. On the other hand, if you're an end user, forced unwillingly into using NAT because your ISP won't (or can't) give you sufficient address space to number all your systems, then the address issues are pressing... (Aside, please don't turn this into a NAT vs anti-NAT debate, I'm not claiming that all users of NAT are unwilling users, just that some are). | - but the routing table | and the underlying shifts in the use of the routing table | is cause for concern. Certainly. Of course, it would help a bit if the backbone ISPs would start routing native IPv6 sometime soon. Doing that is going to add a chunk of routing table size, as it will obviously need to be in parallel with IPv4 for quite a while. But because of that, it also needs to be done before the routing table size has become such a problem that there is no rational way to add routing information to the backbone. kre From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 19 16:59:56 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id FA30125; Tue, 19 Dec 2000 16:59:56 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJ5wPC00720 for deliver-b-i-au; Tue, 19 Dec 2000 16:58:25 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJ5wJv00712 for ; Tue, 19 Dec 2000 16:58:19 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id FA29594; Tue, 19 Dec 2000 16:18:18 +1100 (from bmanning@vacation.karoshi.com) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.4.20]) by mumnunah.cs.mu.OZ.AU with ESMTP id QAA28874 for ; Tue, 19 Dec 2000 16:18:06 +1100 (EST) From: bmanning@vacation.karoshi.com Received: (from bmanning@localhost) by vacation.karoshi.com (8.9.3/8.9.3) id FAA24060 for Big-Internet@munnari.OZ.AU; Tue, 19 Dec 2000 05:07:21 GMT Message-Id: <200012190507.FAA24060@vacation.karoshi.com> Subject: 2x32 To: Big-Internet@munnari.OZ.AU Date: Tue, 19 Dec 2000 05:07:20 +0000 (UCT) X-Mailer: ELM [version 2.5 PL1] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk full IPv4 host routes are identical to the space reserved for routing IPv6 addresses. The IPv6 space is "carved" up with the last 64 bits as MAC address and the first 32 as "address family", leaving the second 32-bit chunk to define routing. It seems that this pushes squarely back on the need to have a manageable routing domain (protocols, tools, migration techniques, et.al.) that may not easily be adopted from the IPv4 experience. --bill From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 19 16:59:58 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id FA29671; Tue, 19 Dec 2000 16:59:58 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJ5wP100722 for deliver-b-i-au; Tue, 19 Dec 2000 16:58:25 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJ5wKv00715 for ; Tue, 19 Dec 2000 16:58:20 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id EA29749; Tue, 19 Dec 2000 15:56:17 +1100 (from randy@psg.com) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by mumnunah.cs.mu.OZ.AU with ESMTP id PAA28589; Tue, 19 Dec 2000 15:56:14 +1100 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 148Eot-000G9u-00; Mon, 18 Dec 2000 20:56:11 -0800 From: Randy Bush Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Elz Cc: Geoff Huston , Big-Internet@munnari.OZ.AU Subject: Re: Addresses or routing... References: <4.3.2.7.2.20001219141411.00acb750@jumble.telstra.net> <20207.977198901@mundamutti.cs.mu.OZ.AU> Message-Id: Date: Mon, 18 Dec 2000 20:56:11 -0800 Precedence: bulk > On the other hand, if you're an end user, forced unwillingly into using > NAT because your ISP won't (or can't) give you sufficient address space > to number all your systems, then the address issues are pressing... or they need to change to an isp which understands and executes allocation policy and can deal with their local address registry. there are also isps which can not configure routers. that does not mean that we need to change router standards. address allocation policies are not an excuse for natting. personally, i think the biggest vector pushing nats is that they come with firewalls and that folk think that they provide security. as usual, it's perception, not reality. ymmv. randy From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 19 17:33:58 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id GA30508; Tue, 19 Dec 2000 17:33:58 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJ6WUS00816 for deliver-b-i-au; Tue, 19 Dec 2000 17:32:30 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJ6WPS00809 for ; Tue, 19 Dec 2000 17:32:25 +1100 (EST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id GA30418; Tue, 19 Dec 2000 17:17:16 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Randy Bush Cc: Geoff Huston , Big-Internet@munnari.OZ.AU Subject: Re: Addresses or routing... In-Reply-To: Your message of "Mon, 18 Dec 2000 20:56:11 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Dec 2000 17:17:16 +1100 Message-Id: <21134.977206636@mundamutti.cs.mu.OZ.AU> Precedence: bulk Date: Mon, 18 Dec 2000 20:56:11 -0800 From: Randy Bush Message-ID: | or they need to change to an isp which understands and executes allocation | policy and can deal with their local address registry. That's not always (economically) possible - not everywhere in the world has an abundance of capable ISPs - many areas have none at all. I guess that a private individual in some remote part of the world could in theory install a dedicated international link to an enlightened ISP in north America or Europe, or something, but I'm not sure it makes sense. | address allocation policies are not an excuse for natting. Unfortunately, often they are. | personally, i think the biggest vector pushing nats but I have no idea at all how much effect the various "features" of NAT have in this regard, I certainly couldn't say that address scarcity is a (much less the) major factor. | is that they come with firewalls and | that folk think that they provide security. as usual, it's perception, not | reality. ymmv. Yes - and the "renumbering benefit", where it is possible to change ISPs, and reconfig your NAT, and not have to renumber anything else, and the "everyone does it this way don't they?" factor ... kre From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 19 17:33:58 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id GA30403; Tue, 19 Dec 2000 17:33:58 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJ6WSH00812 for deliver-b-i-au; Tue, 19 Dec 2000 17:32:28 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJ6WOS00806 for ; Tue, 19 Dec 2000 17:32:24 +1100 (EST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id GA30563; Tue, 19 Dec 2000 17:30:26 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: bmanning@vacation.karoshi.com Cc: Big-Internet@munnari.OZ.AU Subject: Re: 2x32 In-Reply-To: Your message of "Tue, 19 Dec 2000 05:07:20 -0000." <200012190507.FAA24060@vacation.karoshi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Dec 2000 17:30:25 +1100 Message-Id: <21285.977207425@mundamutti.cs.mu.OZ.AU> Precedence: bulk Date: Tue, 19 Dec 2000 05:07:20 +0000 (UCT) From: bmanning@vacation.karoshi.com Message-ID: <200012190507.FAA24060@vacation.karoshi.com> | The IPv6 space is "carved" up with the last 64 bits as MAC | address and the first 32 as "address family", Huh? The first few bits might be considered that way, but only a few, certainly not 32. The last 64 can be (and often are) a MAC address, but again, that isn't required, some of it could be used for routing too (but only ever at a very local level, that will never be seen anywhere that the core cares about - kind of like the /29 and /30 local subnets of the /16 used here). Not that many sites are ever likely to need or desire to do that, but it is possible. | leaving the second 32-bit chunk to define routing. Bigger than that. | It seems that this pushes squarely back on the need to | have a manageable routing domain (protocols, tools, migration techniques, | et.al.) that may not easily be adopted from the IPv4 experience. The major difference is that the IPv6 address allocation is strictly routing hierarchical - only 13 bits of the bigger routing space should ever need to be carried around in a default free router. That is, 8K routes. Some of those routers might also choose to carry around local routes as well, but they never need to (that can all be shovelled off to a separate router for local traffic). kre From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 19 19:19:37 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id IA32201; Tue, 19 Dec 2000 19:19:37 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJ8I5000952 for deliver-b-i-au; Tue, 19 Dec 2000 19:18:05 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJ8I1X00947 for ; Tue, 19 Dec 2000 19:18:01 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id IA32224; Tue, 19 Dec 2000 19:12:14 +1100 (from simon@poole.ch) Received: from maegi2.poole.ch (maegi2.poole.ch [195.49.110.35]) by mumnunah.cs.mu.OZ.AU with ESMTP id TAA00951; Tue, 19 Dec 2000 19:12:09 +1100 (EST) Received: from simonwin (simon-win.poole.ch [172.16.1.5]) by maegi2.poole.ch (8.9.3/8.9.3) with SMTP id JAA65344; Tue, 19 Dec 2000 09:10:47 +0100 (CET) (envelope-from simon@poole.ch) Message-Id: <038701c06993$32689e80$050110ac@poole.ch> From: "Simon Poole" To: "Robert Elz" , "Geoff Huston" Cc: References: <4.3.2.7.2.20001219051657.00ac0780@jumble.telstra.net> Subject: Re: Admin: Just flushing bad addresses from the list Date: Tue, 19 Dec 2000 09:10:47 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Precedence: bulk > One of the concerns at present is an > accelerated growth trend in the BGP table size (www.telstra.net/ops/bgp), > and it was suggested that this list be used to discuss the characteristics > of this growth and the characteristics of routing systems that can operate > efficiently in such large environments. I suppose somebody has to bite the bullet and ask the obvious stupid question: why are we seeing such a growth in /24's? Nearly 15% in just over 4 months? Something is going substantially wrong. Simon From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 19 20:18:11 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA27685; Tue, 19 Dec 2000 20:18:11 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: from localhost (localhost [[UNIX: localhost]]) by murtoa.cs.mu.OZ.AU id eBJ9Gkx01121 for deliver-b-i-au; Tue, 19 Dec 2000 20:16:46 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJ9GdA01116 for ; Tue, 19 Dec 2000 20:16:39 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA00355; Tue, 19 Dec 2000 20:08:42 +1100 (from maarteng@nix00.EU.net) Received: from nix00.EU.net (nix00.EU.net [193.242.95.20]) by mumnunah.cs.mu.OZ.AU with ESMTP id UAA01376 for ; Tue, 19 Dec 2000 20:08:38 +1100 (EST) Received: from maarteng (helo=localhost) by nix00.EU.net with local-esmtp (Exim 3.03 #2) id 148Icw-0001BW-00; Tue, 19 Dec 2000 10:00:06 +0100 Date: Tue, 19 Dec 2000 10:00:06 +0100 (CET) From: maarten geerts X-Sender: maarteng@nix00.EU.net To: Simon Poole Cc: Robert Elz , Geoff Huston , Big-Internet@munnari.OZ.AU Subject: Re: Admin: Just flushing bad addresses from the list In-Reply-To: <038701c06993$32689e80$050110ac@poole.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Precedence: bulk hi all check this site, james here made a nice overview of possible route aggregation. Quite a lot of possibilities to reduce the bgp table http://www.mcvax.org/~jhma/routing/index.html greets, Maarten Geerts kpnqwest ip noc On Tue, 19 Dec 2000, Simon Poole wrote: > > One of the > concerns at present is an > > accelerated growth trend in the BGP table size (www.telstra.net/ops/bgp), > > and it was suggested that this list be used to discuss the characteristics > > of this growth and the characteristics of routing systems that can operate > > efficiently in such large environments. > > > I suppose somebody has to bite the bullet and ask the obvious > stupid question: why are we seeing such a growth in /24's? > Nearly 15% in just over 4 months? Something is going substantially > wrong. > > Simon > > From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 19 20:21:13 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA00131; Tue, 19 Dec 2000 20:21:13 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJ9Jmo01146 for deliver-b-i-au; Tue, 19 Dec 2000 20:19:48 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJ9Jir01143 for ; Tue, 19 Dec 2000 20:19:44 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA00767; Tue, 19 Dec 2000 20:17:00 +1100 (from beri@nix00.EU.net) Received: from nix00.EU.net (nix00.EU.net [193.242.95.20]) by mumnunah.cs.mu.OZ.AU with ESMTP id UAA01433; Tue, 19 Dec 2000 20:14:56 +1100 (EST) Received: from beri (helo=localhost) by nix00.EU.net with local-esmtp (Exim 3.03 #2) id 148Ie0-0001Bq-00; Tue, 19 Dec 2000 10:01:12 +0100 Date: Tue, 19 Dec 2000 10:01:12 +0100 (CET) From: Berislav Todorovic X-Sender: beri@nix00.EU.net To: Simon Poole Cc: Robert Elz , Geoff Huston , Big-Internet@munnari.OZ.AU Subject: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) In-Reply-To: <038701c06993$32689e80$050110ac@poole.ch> Message-Id: X-Ncc-Regid: eu.eunet Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Berislav Todorovic Precedence: bulk On Tue, 19 Dec 2000, Simon Poole wrote: >> I suppose somebody has to bite the bullet and ask the obvious stupid >> question: why are we seeing such a growth in /24's? Nearly 15% in just >> over 4 months? Something is going substantially wrong. Because there are a lot of careless people announcing 256 /24's thinking that such a strategy would bring them some benefit. A brief analysis of the last Tony Bates' CIDR report shows that we could have 70000 prefixes today very easily - just a bit of tidying up work has to be done. Regards, Beri --------- Berislav Todorovic, Network Engineer --------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri@kpnqwest.net <=> beri@EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 19 21:39:52 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id KA01972; Tue, 19 Dec 2000 21:39:52 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJAcBX01211 for deliver-b-i-au; Tue, 19 Dec 2000 21:38:11 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJAbYA01206 for ; Tue, 19 Dec 2000 21:37:35 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id KA01643; Tue, 19 Dec 2000 21:19:17 +1100 (from gih@telstra.net) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by mumnunah.cs.mu.OZ.AU with ESMTP id VAA02052; Tue, 19 Dec 2000 21:19:13 +1100 (EST) Received: from tecra.telstra.net ([203.10.60.18]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id VAA52496; Tue, 19 Dec 2000 21:16:01 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001219205207.00ad6aa0@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Dec 2000 21:15:54 +1100 To: Berislav Todorovic From: Geoff Huston Subject: Re: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) Cc: Simon Poole , Robert Elz , Big-Internet@munnari.OZ.AU In-Reply-To: References: <038701c06993$32689e80$050110ac@poole.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk >A brief analysis of the last Tony Bates' CIDR report shows that we could >have 70000 prefixes today very easily - just a bit of tidying up work has >to be done. While some 40,000 route advertisements are refinements of existing aggregates (40% of the routing space), just 5,000 of these specifics share an AS Path with the aggregate - i.e. at fist pass it appears that not 30,000 but just 5,000 routes are potential candidates from such a perspective. But even this is not correct, as it neglects to take into account the use of specifics in local traffic engineering applications. From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 01:49:02 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id OA05751; Wed, 20 Dec 2000 01:49:02 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJElQn01460 for deliver-b-i-au; Wed, 20 Dec 2000 01:47:26 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJElLf01453 for ; Wed, 20 Dec 2000 01:47:21 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id OA05108; Wed, 20 Dec 2000 01:41:04 +1100 (from crawdad@gungnir.fnal.gov) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by mumnunah.cs.mu.OZ.AU with ESMTP id BAA04664 for ; Wed, 20 Dec 2000 01:41:00 +1100 (EST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA06893 for ; Tue, 19 Dec 2000 08:37:38 -0600 (CST) Message-Id: <200012191437.IAA06893@gungnir.fnal.gov> To: Big-Internet@munnari.OZ.AU From: "Matt Crawford" Subject: Re: 2x32 In-Reply-To: Your message of Tue, 19 Dec 2000 05:07:20 GMT. <200012190507.FAA24060@vacation.karoshi.com> Date: Tue, 19 Dec 2000 08:37:38 -0600 Sender: crawdad@gungnir.fnal.gov Precedence: bulk > full IPv4 host routes are identical to the space reserved for routing IPv6 > addresses. The IPv6 space is "carved" up with the last 64 bits as MAC > address and the first 32 as "address family", leaving the second 32-bit chunk > to define routing. Say what? From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 01:49:03 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id OA05309; Wed, 20 Dec 2000 01:49:03 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJElIe01450 for deliver-b-i-au; Wed, 20 Dec 2000 01:47:18 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJElDf01445 for ; Wed, 20 Dec 2000 01:47:14 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id OA04345; Wed, 20 Dec 2000 01:29:27 +1100 (from crawdad@gungnir.fnal.gov) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by mumnunah.cs.mu.OZ.AU with ESMTP id BAA04525 for ; Wed, 20 Dec 2000 01:29:24 +1100 (EST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA06787; Tue, 19 Dec 2000 08:25:58 -0600 (CST) Message-Id: <200012191425.IAA06787@gungnir.fnal.gov> To: Frank Kastenholz Cc: Big-Internet@munnari.OZ.AU From: "Matt Crawford" Subject: Re: Admin: Just flushing bad addresses from the list In-Reply-To: Your message of Mon, 18 Dec 2000 20:29:55 EST. <5.0.0.25.2.20001218202822.00a754f0@schultz.argon.com> Date: Tue, 19 Dec 2000 08:25:58 -0600 Sender: crawdad@gungnir.fnal.gov Precedence: bulk > If I recall correctly, it's the size of the BGP > tables that is causing the current agita... All one > needs to do is look at your graph to run screaming > for the Valium (or to buy stock in SRAM companies...) I Am Not A Real Routing Geek But I've been told and convinced that it's not the SIZE of the forwarding table but the computrons it takes to compute it and, to a lesser extent, the bandwidth it takes to communicate the updates. From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 01:49:01 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id OA05243; Wed, 20 Dec 2000 01:49:01 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJElPd01458 for deliver-b-i-au; Wed, 20 Dec 2000 01:47:25 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJElGf01448 for ; Wed, 20 Dec 2000 01:47:17 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id OA04617; Wed, 20 Dec 2000 01:12:32 +1100 (from jprovo@ma.ultranet.com) Received: from elektra.ultra.net (elektra.ultra.net [146.115.9.13]) by mumnunah.cs.mu.OZ.AU with ESMTP id BAA04360 for ; Wed, 20 Dec 2000 01:12:10 +1100 (EST) Received: (from jprovo@localhost) by elektra.ultra.net (8.8.8/ult.n26500) id JAA04825; Tue, 19 Dec 2000 09:10:45 -0500 (EST) Date: Tue, 19 Dec 2000 09:10:45 -0500 From: Joe Provo To: Geoff Huston Cc: Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) Message-Id: <20001219091045.A17058@ultra.net> Reply-To: joe.provo@rcn.com References: <038701c06993$32689e80$050110ac@poole.ch> <4.3.2.7.2.20001219205207.00ad6aa0@jumble.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <4.3.2.7.2.20001219205207.00ad6aa0@jumble.telstra.net>; from gih@telstra.net on Tue, Dec 19, 2000 at 09:15:54PM +1100 X-Pgp-Key: http://www.ultra.net/~jprovo/pgp.txt X-Disclaimer: "I'm the only one foolish enough to claim these opinions." Organization: Network Planning and Design, RCN Precedence: bulk On Tue, Dec 19, 2000 at 09:15:54PM +1100, Geoff Huston wrote: [snip] > While some 40,000 route advertisements are refinements of existing > aggregates (40% of the routing space), just 5,000 of these specifics > share an AS Path with the aggregate - i.e. at fist pass it appears that > not 30,000 but just 5,000 routes are potential candidates from such a > perspective. But even this is not correct, as it neglects to take into > account the use of specifics in local traffic engineering applications. Why can't such "local" traffic engineering applications, uh, just stay local? Announcing an aggregate & tweaked [communities, prefs, MEDs, whatever] more-specifics to one's transit provider is all fine and dandy, but the the more specifics should be tagged NO_ADVERTISE so the rest of us don't see them. If one's transit provider mesh is so inadequate that you don't get the benefit you seek, then we're speaking of inter-provider TE rather than local, no? Cheers, Joe -- Joe Provo Voice 508.486.7471 Director, Internet Planning & Design Fax 508.229.2375 Network Deployment & Management, RCN From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 01:54:10 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id OA05308; Wed, 20 Dec 2000 01:54:10 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJEqk401524 for deliver-b-i-au; Wed, 20 Dec 2000 01:52:46 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJEqgG01521 for ; Wed, 20 Dec 2000 01:52:42 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id OA04607; Wed, 20 Dec 2000 01:51:26 +1100 (from randy@psg.com) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by mumnunah.cs.mu.OZ.AU with ESMTP id BAA04771; Wed, 20 Dec 2000 01:51:23 +1100 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 148O39-000EjX-00; Tue, 19 Dec 2000 06:47:31 -0800 From: Randy Bush Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Berislav Todorovic Cc: Simon Poole , Robert Elz , Geoff Huston , Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) References: <038701c06993$32689e80$050110ac@poole.ch> Message-Id: Date: Tue, 19 Dec 2000 06:47:31 -0800 Precedence: bulk >>> I suppose somebody has to bite the bullet and ask the obvious stupid >>> question: why are we seeing such a growth in /24's? Nearly 15% in just >>> over 4 months? Something is going substantially wrong. > > Because there are a lot of careless people announcing 256 /24's thinking > that such a strategy would bring them some benefit. > > A brief analysis of the last Tony Bates' CIDR report shows that we could > have 70000 prefixes today very easily - just a bit of tidying up work has > to be done. as the reports being shoved in everybody's face seem to do little good, perhaps it is time to filter a bit more aggressively to get the message through. randy From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 01:59:29 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id OA05745; Wed, 20 Dec 2000 01:59:29 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJEw1Q01578 for deliver-b-i-au; Wed, 20 Dec 2000 01:58:01 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJEvwc01575 for ; Wed, 20 Dec 2000 01:57:58 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id OA05034; Wed, 20 Dec 2000 01:55:18 +1100 (from fkastenholz@unispherenetworks.com) Received: from shultz.argon.com (shultz.argon.com [208.234.161.2]) by mumnunah.cs.mu.OZ.AU with ESMTP id BAA04789; Wed, 20 Dec 2000 01:55:11 +1100 (EST) Received: from fkastenholzpc.unispherenetworks.com (dhcp1.argon.com [208.234.161.16]) by shultz.argon.com (8.10.0/8.10.0) with ESMTP id eBJEr6129714; Tue, 19 Dec 2000 09:53:06 -0500 (EST) Message-Id: <5.0.0.25.2.20001219095942.00a54300@schultz.argon.com> X-Sender: kasten@schultz.argon.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 19 Dec 2000 10:05:06 -0500 To: Robert Elz , Geoff Huston From: Frank Kastenholz Subject: Re: Addresses or routing... Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <20207.977198901@mundamutti.cs.mu.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk At 03:08 PM 12/19/00 +1100, Robert Elz wrote: > Date: Tue, 19 Dec 2000 14:15:48 +1100 > From: Geoff Huston > Message-ID: <4.3.2.7.2.20001219141411.00acb750@jumble.telstra.net> > > | That's right - the address issues are, today, not > | really a pressing issue > >If you're a backbone type ISP, and your concern is managing the routers >in the backbone, that's probably true. > >On the other hand, if you're an end user, forced unwillingly into using >NAT because your ISP won't (or can't) give you sufficient address space >to number all your systems, then the address issues are pressing... >(Aside, please don't turn this into a NAT vs anti-NAT debate, I'm not >claiming that all users of NAT are unwilling users, just that some are). Yes, except that forcing end users to use NAT will not cause the Internet to melt down. It may be unpleasant, expensive, inconvenient, or politically incorrect. But it's not terminal. If BGP gets overwhelmed and starts failing, then the Internet _will_ stop. >Certainly. Of course, it would help a bit if the backbone ISPs would >start routing native IPv6 sometime soon. Doing that is going to add >a chunk of routing table size, as it will obviously need to be in >parallel with IPv4 for quite a while. But because of that, it also needs >to be done before the routing table size has become such a problem that >there is no rational way to add routing information to the backbone. Just using IPv6 will _not_ fix the BGP problem. We still have to route all those addresses. My guess is that if ISPs start routing V6 then A) there will be bigger BGP tables because it has to carry around both V4 and V6 and B) the V6 tables will grow bigger faster since CIDR and strong address allocation policies in V4 are forcing people to use small chunks of space and use lots of aggregatable space. 6 will have lots of address bits, people will demand their own globally routable addresses (i.e. not accept them from their service providers)... Frank Kastenholz From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 02:25:27 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id PA05987; Wed, 20 Dec 2000 02:25:27 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJFO2E01627 for deliver-b-i-au; Wed, 20 Dec 2000 02:24:02 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJFNxX01624 for ; Wed, 20 Dec 2000 02:23:59 +1100 (EST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id PA05831; Wed, 20 Dec 2000 02:19:23 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Frank Kastenholz Cc: Big-Internet@munnari.OZ.AU Subject: Re: Addresses or routing... In-Reply-To: Your message of "Tue, 19 Dec 2000 10:05:06 CDT." <5.0.0.25.2.20001219095942.00a54300@schultz.argon.com> Date: Wed, 20 Dec 2000 02:19:22 +1100 Message-Id: <25308.977239162@mundamutti.cs.mu.OZ.AU> Precedence: bulk Date: Tue, 19 Dec 2000 10:05:06 -0500 From: Frank Kastenholz Message-ID: <5.0.0.25.2.20001219095942.00a54300@schultz.argon.com> | Yes, except that forcing end users to use NAT will not cause | the Internet to melt down. It may be unpleasant, expensive, | inconvenient, or politically incorrect. But it's not terminal. | If BGP gets overwhelmed and starts failing, then the Internet | _will_ stop. I don't doubt that (or rather, I do doubt that, as these days there's simply too many $'s tied up in the internet to allow it to fail - whatever the problems, a way will be found to overcome them - but the seriousness of the potential problem I do understand). I wasn't attempting to rank the issues, I was just responding to the assertion that address scareceness is not a pressing problem - it is. | Just using IPv6 will _not_ fix the BGP problem. We still have to route | all those addresses. My guess is that if ISPs start routing | V6 then | A) there will be bigger BGP tables because it has to carry around | both V4 and V6 and Yes, that's what I think I said (and why it needs to start before the BGP tables reach the state where IPv6 routes can no longer be carried). | B) the V6 tables will grow bigger faster since CIDR and strong | address allocation policies in V4 are forcing people to use | small chunks of space and use lots of aggregatable space. | 6 will have lots of address bits, people will demand their own | globally routable addresses (i.e. not accept them from their | service providers)... With IPv6 there is (supposed to be) no other way to get addresses. if the registries and ISPs can manage to not assign more than a trivial number of global addresses to people now, when a whole bunch of other people who happened to be around earlier plainly have global portable addresses, they they really should have no great problem assigning (essentially) unlimited blocks of aggregable global addresses. What's more, the backbone (transit) providers can (and should) start out by filtering at /18 (or /20 or whatever is the prefix with the 13 bits of allocated address, and the N constant bits of "format type") and simply not allowing, right from day 1, any longer prefixes into the BGP tables. kre From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 02:37:06 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id PA06335; Wed, 20 Dec 2000 02:37:06 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJFZfQ01657 for deliver-b-i-au; Wed, 20 Dec 2000 02:35:41 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJFZbM01654 for ; Wed, 20 Dec 2000 02:35:37 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id PA06074; Wed, 20 Dec 2000 02:30:51 +1100 (from brian@hursley.ibm.com) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by mumnunah.cs.mu.OZ.AU with ESMTP id CAA05164 for ; Wed, 20 Dec 2000 02:30:44 +1100 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id HAA31904; Tue, 19 Dec 2000 07:23:25 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA22284; Tue, 19 Dec 2000 07:28:05 -0800 Message-Id: <3A3F7E36.AAC08B94@hursley.ibm.com> Date: Tue, 19 Dec 2000 09:26:46 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr Mime-Version: 1.0 To: Bill Woodcock Cc: Geoff Huston , Big-Internet@munnari.OZ.AU Subject: Re: Admin: Just flushing bad addresses from the list References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Bill Woodcock wrote: > > > After correcting for the flapping /8's I get a decent fit with > > daily growth of 0.0194% - extrapolating that blindly forward > > gets to 4.3B in April 2020. > > My recollection is that people have been saying "about 2020" ever since > the growth curve re-stabilized after CIDR deployment. Which is > interesting, since it seems like the curve has changed several times since > then. And of course this obscures the growth in pseudo-addressable hosts, i.e. those behind NATs. Which is one reason to discuss the method before we discuss the data. Brian From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 02:37:21 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id PA05975; Wed, 20 Dec 2000 02:37:21 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJFZva01662 for deliver-b-i-au; Wed, 20 Dec 2000 02:35:57 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJFZrM01659 for ; Wed, 20 Dec 2000 02:35:53 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id PA06123; Wed, 20 Dec 2000 02:29:23 +1100 (from brian@hursley.ibm.com) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by mumnunah.cs.mu.OZ.AU with ESMTP id CAA05143; Wed, 20 Dec 2000 02:29:12 +1100 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id HAA53360; Tue, 19 Dec 2000 07:21:52 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA20782; Tue, 19 Dec 2000 07:26:31 -0800 Message-Id: <3A3F7DD8.41661AA8@hursley.ibm.com> Date: Tue, 19 Dec 2000 09:25:12 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr Mime-Version: 1.0 To: Randy Bush Cc: Geoff Huston , Robert Elz , Jim Dixon , Big-Internet@munnari.OZ.AU Subject: Re: Admin: Just flushing bad addresses from the list References: <4.3.2.7.2.20001219051657.00ac0780@jumble.telstra.net> <3A3E9AE5.DC006C42@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Randy Bush wrote: > > > Plus a realistic assessment of IPv4 address space usage > > i suspect that different folk's versions of 'realistic' are dissimilar. Which is exactly why I suggested in private to Frank Solensky that we discuss the *method* for making the assessment first, before attempting to look at any data. Brian From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 02:49:03 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id PA06466; Wed, 20 Dec 2000 02:49:03 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJFlXw01744 for deliver-b-i-au; Wed, 20 Dec 2000 02:47:33 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJFlSp01739 for ; Wed, 20 Dec 2000 02:47:29 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id PA06363; Wed, 20 Dec 2000 02:46:14 +1100 (from freedman@freedman.net) Received: from freedman.net (freedman.net [207.106.3.15]) by mumnunah.cs.mu.OZ.AU with ESMTP id CAA05342 for ; Wed, 20 Dec 2000 02:46:05 +1100 (EST) Received: (from freedman@localhost) by freedman.net (8.8.7/8.8.7) id KAA21140; Tue, 19 Dec 2000 10:18:43 -0500 Message-Id: <200012191518.KAA21140@freedman.net> Subject: Re: Admin: Just flushing bad addresses from the list To: crawdad@fnal.gov (Matt Crawford) Date: Tue, 19 Dec 2000 10:18:43 -0500 (EST) From: Avi Freedman Cc: fkastenholz@unispherenetworks.com (Frank Kastenholz), Big-Internet@munnari.OZ.AU In-Reply-To: <200012191425.IAA06787@gungnir.fnal.gov> from "Matt Crawford" at Dec 19, 2000 08:25:58 AM X-Mailer: ELM [version 2.5 PL0] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk It's not bandwidth at all. Size is an issue today for people with relatively-recent routers, and computrons certainly is... Avi > > > If I recall correctly, it's the size of the BGP > > tables that is causing the current agita... All one > > needs to do is look at your graph to run screaming > > for the Valium (or to buy stock in SRAM companies...) > > I Am Not A Real Routing Geek But > > I've been told and convinced that it's not the SIZE of the > forwarding table but the computrons it takes to compute it and, to a > lesser extent, the bandwidth it takes to communicate the updates. > From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 09:47:09 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA11300; Wed, 20 Dec 2000 09:47:09 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJMjNA03045 for deliver-b-i-au; Wed, 20 Dec 2000 09:45:23 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJMjH503042 for ; Wed, 20 Dec 2000 09:45:19 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id QA06994; Wed, 20 Dec 2000 03:51:41 +1100 (from Valdis.Kletnieks@vt.edu) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mumnunah.cs.mu.OZ.AU with ESMTP id DAA07160 for ; Wed, 20 Dec 2000 03:51:37 +1100 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eBJGkSCW209984; Tue, 19 Dec 2000 11:46:28 -0500 Message-Id: <200012191646.eBJGkSCW209984@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: Matt Crawford Cc: Big-Internet@munnari.OZ.AU Subject: Re: Admin: Just flushing bad addresses from the list In-Reply-To: Your message of "Tue, 19 Dec 2000 08:25:58 CST." <200012191425.IAA06787@gungnir.fnal.gov> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-751797216P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 19 Dec 2000 11:46:28 -0500 Precedence: bulk --==_Exmh_-751797216P Content-Type: text/plain; charset=us-ascii On Tue, 19 Dec 2000 08:25:58 CST, Matt Crawford said: > I've been told and convinced that it's not the SIZE of the > forwarding table but the computrons it takes to compute it and, to a > lesser extent, the bandwidth it takes to communicate the updates. And this is why BGP route flap damping exists. Unfortunately, for a sufficiently large and complicated topology, I am told it's possible for the equivalent of cardiac fibrillation to occur, even with agressing flap damping in place. But I'm just a sysadmin, the router gods are down the hall. ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-751797216P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOj+Q43At5Vm009ewEQLExgCgjKySwqhQsJXsKhPb/wCCHOPk0cMAnRc6 XTPB6RTG381atJQRoNX/IyPL =BEiY -----END PGP SIGNATURE----- --==_Exmh_-751797216P-- From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 09:47:13 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA11257; Wed, 20 Dec 2000 09:47:13 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJMjo003050 for deliver-b-i-au; Wed, 20 Dec 2000 09:45:50 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJMjk503047 for ; Wed, 20 Dec 2000 09:45:46 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id QA07290; Wed, 20 Dec 2000 03:43:18 +1100 (from kurtis@kpnqwest.net) Received: from calvin.eunet.se (calvin.eunet.se [195.43.226.66]) by mumnunah.cs.mu.OZ.AU with ESMTP id DAA07062 for ; Wed, 20 Dec 2000 03:43:14 +1100 (EST) Received: from calvin.eunet.se (calvin.eunet.se [195.43.226.66]) by calvin.eunet.se (8.9.3/8.9.3) with ESMTP id RAA27605; Tue, 19 Dec 2000 17:39:08 +0100 (MET) Date: Tue, 19 Dec 2000 17:39:08 +0100 (MET) From: Kurt Erik Lindqvist X-Sender: kurtis@calvin.eunet.se Reply-To: Kurt Erik Lindqvist To: Geoff Huston Cc: Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) In-Reply-To: <4.3.2.7.2.20001219205207.00ad6aa0@jumble.telstra.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > is not correct, as it neglects to take into account the use of specifics in > local traffic engineering applications. I thought local traffic engineering applications where just that - local. - kurtis - Kurt Erik Lindqvist Kurtis.Lindqvist@KPNQwest.SE KPNQwest Sweden @ The speed of light http://www.kpnqwest.se PO Box 23163 S-10435 Stockholm From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 09:48:22 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA11688; Wed, 20 Dec 2000 09:48:22 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJMksR03055 for deliver-b-i-au; Wed, 20 Dec 2000 09:46:55 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJMkq503052 for ; Wed, 20 Dec 2000 09:46:52 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id RA06326; Wed, 20 Dec 2000 04:33:58 +1100 (from gih@telstra.net) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by mumnunah.cs.mu.OZ.AU with ESMTP id EAA07601; Wed, 20 Dec 2000 04:33:47 +1100 (EST) Received: from tecra.telstra.net ([203.10.60.4]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id EAA66084; Wed, 20 Dec 2000 04:31:16 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001220042838.00ad3cc0@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Dec 2000 04:31:16 +1100 To: Robert Elz From: Geoff Huston Subject: Re: 2x32 Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <21285.977207425@mundamutti.cs.mu.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk >The major difference is that the IPv6 address allocation is strictly >routing hierarchical - only 13 bits of the bigger routing space should >ever need to be carried around in a default free router. That is, 8K >routes. Some of those routers might also choose to carry around >local routes as well, but they never need to (that can all be shovelled off >to a separate router for local traffic). And here's where I start to wonder - what it bandwidth were so cheap that _every_ ISP in the world and _every_ major "I'm just so important" customer had a link to Mae-Somewhere and had a co-located router there. Would this hierarchical model of routing work across the very dense interconnection mesh of Mae-Somewhere? From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 09:49:26 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA11286; Wed, 20 Dec 2000 09:49:26 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: from localhost (localhost [[UNIX: localhost]]) by murtoa.cs.mu.OZ.AU id eBJMm2M03076 for deliver-b-i-au; Wed, 20 Dec 2000 09:48:02 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJMlt503073 for ; Wed, 20 Dec 2000 09:47:59 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id RA07303; Wed, 20 Dec 2000 04:04:21 +1100 (from bass@www.silkroad.com) Received: from www.silkroad.com ([64.14.111.22]) by mumnunah.cs.mu.OZ.AU with ESMTP id EAA07307 for ; Wed, 20 Dec 2000 04:04:08 +1100 (EST) Received: from ibs (ibs.silkroad.com [64.14.111.24]) by www.silkroad.com (8.11.1/8.9.1) with SMTP id eBJGkJO27341 for ; Tue, 19 Dec 2000 11:46:20 -0500 Message-Id: <000b01c069da$3194db80$186f0e40@silkroad.com> Reply-To: "Tim Bass" From: "Tim Bass" To: References: <25308.977239162@mundamutti.cs.mu.OZ.AU> Subject: Re: Addresses or routing... Date: Tue, 19 Dec 2000 11:38:58 -0500 Organization: Silk Road Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Precedence: bulk It is good to see that die-hard technical people are considering the engineering reality of $$$ and business. Many now realize that these 'temporary fixes' such as NAT and CIDR end up becoming concrete and there network-cries of 'it is wrong, but just temporary' are now known to be false arguements. NAT and CIDR only were approved by IAB and IETF because of the emotion and false argument that they were 'only temporary' (documented in IEEE Network in the link below): The same reality sould be considered carefully when making statements regarding NAT and IP routing today. Most large organizations cannot afford the $$$s to employ folks to manage overly complex networks, complex by design kludges and other hacks like NAT which break the end-to-end model. BTW, the simplicity of the end-to-end model is not only academic dreamwork, it is the reality of managing costs and long term complexity. Now, what we see are that organizations who want to do IPSEC now (or just simply SSH) for secure remote management do not do it because NAT breaks cryptographic systems. Yes, of course an organization can 'make the kludge' work, but the costs are very high because of the complexity that continues to be built into the network infrastructure. Complexity translated to costs and big $$$$ over time. In a nutshell, NAT is not the solution for IP address space management, better routing algorithms are. In the current state of affairs, the world is at an impasse trying to do IPSEC (which is complex enough) and to do it in a NAT environment. Organizations simply cannot afford to be held hostage to complex technology kludges which continue to be causal to problems in global routing algorithms. This is an old topic documented in IEEE Network (CIDR and PBA focused): http://www.silkroad.com/papers/html/pba/n1.html It is encouraging to read people discussing Internet engineering in terms of $$$ and business realities. Another reality is that networks must designed with the simplicity principle in mind, not 'layers of complexity' to keeps costs down. It would be more encouraging, however, to not read people proposing that the NAT kludge be continued. It is time to work on a new algorithm and method for global routing. Many have been submitted by academics worldwide. None are considered nor adopted by the vendors. The operational and sustainment costs of all these issues continue to be very high getting higher. As a final note, understanding the controversy this brings, I hope that any replys will will professional and objective and will not be wrapped in the 'world and internet is falling apart' emotional replys that have no foundation nor merit. Finest Regards, Tim It is encouraging to read ----- Original Message ----- From: "Robert Elz" To: "Frank Kastenholz" Cc: Sent: Tuesday, December 19, 2000 10:19 AM Subject: Re: Addresses or routing... > Date: Tue, 19 Dec 2000 10:05:06 -0500 > From: Frank Kastenholz > Message-ID: <5.0.0.25.2.20001219095942.00a54300@schultz.argon.com> > > | Yes, except that forcing end users to use NAT will not cause > | the Internet to melt down. It may be unpleasant, expensive, > | inconvenient, or politically incorrect. But it's not terminal. > | If BGP gets overwhelmed and starts failing, then the Internet > | _will_ stop. > > I don't doubt that (or rather, I do doubt that, as these days there's > simply too many $'s tied up in the internet to allow it to fail - whatever > the problems, a way will be found to overcome them - but the seriousness > of the potential problem I do understand). I wasn't attempting to rank > the issues, I was just responding to the assertion that address scareceness > is not a pressing problem - it is. > > | Just using IPv6 will _not_ fix the BGP problem. We still have to route > | all those addresses. My guess is that if ISPs start routing > | V6 then > | A) there will be bigger BGP tables because it has to carry around > | both V4 and V6 and > > Yes, that's what I think I said (and why it needs to start before the > BGP tables reach the state where IPv6 routes can no longer be carried). > > | B) the V6 tables will grow bigger faster since CIDR and strong > | address allocation policies in V4 are forcing people to use > | small chunks of space and use lots of aggregatable space. > | 6 will have lots of address bits, people will demand their own > | globally routable addresses (i.e. not accept them from their > | service providers)... > > With IPv6 there is (supposed to be) no other way to get addresses. > if the registries and ISPs can manage to not assign more than a trivial > number of global addresses to people now, when a whole bunch of other > people who happened to be around earlier plainly have global portable > addresses, they they really should have no great problem assigning > (essentially) unlimited blocks of aggregable global addresses. > > What's more, the backbone (transit) providers can (and should) start out > by filtering at /18 (or /20 or whatever is the prefix with the 13 > bits of allocated address, and the N constant bits of "format type") > and simply not allowing, right from day 1, any longer prefixes into the > BGP tables. > > kre > From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 09:49:53 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA11385; Wed, 20 Dec 2000 09:49:53 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJMmTf03089 for deliver-b-i-au; Wed, 20 Dec 2000 09:48:29 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJMmQ503084 for ; Wed, 20 Dec 2000 09:48:26 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id RA07319; Wed, 20 Dec 2000 04:30:07 +1100 (from gih@telstra.net) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by mumnunah.cs.mu.OZ.AU with ESMTP id EAA07576 for ; Wed, 20 Dec 2000 04:29:46 +1100 (EST) Received: from tecra.telstra.net ([203.10.60.4]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id EAA65871; Wed, 20 Dec 2000 04:27:10 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001220041539.00ac62a0@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Dec 2000 04:19:07 +1100 To: Kurt Erik Lindqvist From: Geoff Huston Subject: Re: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) Cc: Big-Internet@munnari.OZ.AU In-Reply-To: References: <4.3.2.7.2.20001219205207.00ad6aa0@jumble.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk At 12/19/00 05:39 PM +0100, Kurt Erik Lindqvist wrote: > > is not correct, as it neglects to take into account the use of specifics in > > local traffic engineering applications. > >I thought local traffic engineering applications where just that - local. If only that were true. A "problem" with BGP is that there are a paucity of commonly defined attributes, and often the only settings you have are "neighbor" (No Export) and "global". Now if you want to affect path selection of your neighbor's neighbor (and my observation is that this is quite common) then you turn on the global switch and _everyone_ gets to see it. From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 09:51:01 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA11156; Wed, 20 Dec 2000 09:51:01 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJMnY203114 for deliver-b-i-au; Wed, 20 Dec 2000 09:49:34 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJMnU503107 for ; Wed, 20 Dec 2000 09:49:30 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id RA07617; Wed, 20 Dec 2000 04:09:19 +1100 (from cmj@3Com.com) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by mumnunah.cs.mu.OZ.AU with ESMTP id EAA07352 for ; Wed, 20 Dec 2000 04:09:14 +1100 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id JAA15577; Tue, 19 Dec 2000 09:05:38 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id JAA18715; Tue, 19 Dec 2000 09:05:38 -0800 (PST) Received: from cyndi (vpn-242.nsd.3com.com [129.213.205.242]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id JAA19470; Tue, 19 Dec 2000 09:05:37 -0800 (PST) Message-Id: <3.0.6.32.20001219090943.02b2e2c0@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 19 Dec 2000 09:09:43 -0800 To: "Matt Crawford" , Big-Internet@munnari.OZ.AU From: Cyndi Jung Subject: Re: 2x32 In-Reply-To: <200012191437.IAA06893@gungnir.fnal.gov> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk I think this is assuming the longest prefix that makes it into the non-default routing tables is a /48. Cyndi At 08:37 AM 12/19/00 -0600, Matt Crawford wrote: >> full IPv4 host routes are identical to the space reserved for routing IPv6 >> addresses. The IPv6 space is "carved" up with the last 64 bits as MAC >> address and the first 32 as "address family", leaving the second 32-bit chunk >> to define routing. > >Say what? > > From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 09:51:58 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA11138; Wed, 20 Dec 2000 09:51:58 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJMoVV03158 for deliver-b-i-au; Wed, 20 Dec 2000 09:50:31 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJMoQ503154 for ; Wed, 20 Dec 2000 09:50:26 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id RA07831; Wed, 20 Dec 2000 04:52:31 +1100 (from gih@telstra.net) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by mumnunah.cs.mu.OZ.AU with ESMTP id EAA07850; Wed, 20 Dec 2000 04:52:29 +1100 (EST) Received: from tecra.telstra.net ([203.10.60.4]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id EAA66759; Wed, 20 Dec 2000 04:49:57 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001220044541.00b0b290@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Dec 2000 04:49:51 +1100 To: Robert Elz From: Geoff Huston Subject: Re: Addresses or routing... Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <20207.977198901@mundamutti.cs.mu.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk > | - but the routing table > | and the underlying shifts in the use of the routing table > | is cause for concern. > >Certainly. Of course, it would help a bit if the backbone ISPs would >start routing native IPv6 sometime soon. Doing that is going to add >a chunk of routing table size, as it will obviously need to be in >parallel with IPv4 for quite a while. But because of that, it also needs >to be done before the routing table size has become such a problem that >there is no rational way to add routing information to the backbone. ISPs are often not the worlds most sophisticated economists, and even if they identify longer term propositions, their shareholders have more immediate concerns. So the ISP industry adopts the position of 'show me the paying customer and I'll route the packet'. This can become a stalemate, because many customers are waiting for the ISP to jump first to reduce the cost of support, while the ISP is not seeing competitive leakage of customers, and is at this point not strongly motivated to spend the money for deployment in advance. Geoff **I am NOT speaking for my employer - this is a PURELY personal view** From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 09:52:37 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA11210; Wed, 20 Dec 2000 09:52:37 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJMpBJ03177 for deliver-b-i-au; Wed, 20 Dec 2000 09:51:11 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJMp6503174 for ; Wed, 20 Dec 2000 09:51:06 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id RA08070; Wed, 20 Dec 2000 04:55:43 +1100 (from gih@telstra.net) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by mumnunah.cs.mu.OZ.AU with ESMTP id EAA07900; Wed, 20 Dec 2000 04:55:41 +1100 (EST) Received: from tecra.telstra.net ([203.10.60.4]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id EAA66943; Wed, 20 Dec 2000 04:53:09 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001220045115.00aebda0@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Dec 2000 04:53:10 +1100 To: Robert Elz From: Geoff Huston Subject: Re: Addresses or routing... Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <21134.977206636@mundamutti.cs.mu.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk >Yes - and the "renumbering benefit", where it is possible to change ISPs, >and reconfig your NAT, and not have to renumber anything else, and the >"everyone does it this way don't they?" factor ... Customers I speak to see this as important. Again I would argue that this is a side effect of provider-based hierarchy address allocation policies where customer access to provider-independent address space is limited, so NATY and a /24 advertisement multi-homed to a number of providers makes a whole lot sense to them. And. Geoff From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 09:53:25 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA11448; Wed, 20 Dec 2000 09:53:25 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJMpw803196 for deliver-b-i-au; Wed, 20 Dec 2000 09:51:58 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJMpp503193 for ; Wed, 20 Dec 2000 09:51:52 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id RA08082; Wed, 20 Dec 2000 04:49:26 +1100 (from kurtis@kpnqwest.net) Received: from calvin.eunet.se (calvin.eunet.se [195.43.226.66]) by mumnunah.cs.mu.OZ.AU with ESMTP id EAA07805 for ; Wed, 20 Dec 2000 04:49:22 +1100 (EST) Received: from calvin.eunet.se (calvin.eunet.se [195.43.226.66]) by calvin.eunet.se (8.9.3/8.9.3) with ESMTP id SAA01266; Tue, 19 Dec 2000 18:44:15 +0100 (MET) Date: Tue, 19 Dec 2000 18:44:14 +0100 (MET) From: Kurt Erik Lindqvist X-Sender: kurtis@calvin.eunet.se Reply-To: Kurt Erik Lindqvist To: Geoff Huston Cc: Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) In-Reply-To: <4.3.2.7.2.20001220041539.00ac62a0@jumble.telstra.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > > > is not correct, as it neglects to take into account the use of specifics in > > > local traffic engineering applications. > > > >I thought local traffic engineering applications where just that - local. > > If only that were true. > > A "problem" with BGP is that there are a paucity of commonly defined > attributes, and often the only settings you have are "neighbor" > (No Export) and "global". Now if you want to affect path selection > of your neighbor's neighbor (and my observation is that this is > quite common) then you turn on the global switch and _everyone_ > gets to see it. The question here is ofcourse why would you? What is it that you need to announce longer (and more) prefixes for that you can't do with other methods (like chaning your upstream)? Best regards, - kurtis - Kurt Erik Lindqvist Kurtis.Lindqvist@KPNQwest.SE KPNQwest Sweden @ The speed of light http://www.kpnqwest.se PO Box 23163 S-10435 Stockholm From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 09:54:10 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA11277; Wed, 20 Dec 2000 09:54:10 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJMqcI03223 for deliver-b-i-au; Wed, 20 Dec 2000 09:52:38 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJMqY503216 for ; Wed, 20 Dec 2000 09:52:34 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id RA08217; Wed, 20 Dec 2000 04:52:34 +1100 (from gih@telstra.net) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by mumnunah.cs.mu.OZ.AU with ESMTP id EAA07849; Wed, 20 Dec 2000 04:52:28 +1100 (EST) Received: from tecra.telstra.net ([203.10.60.4]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id EAA66754; Wed, 20 Dec 2000 04:49:56 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001220043711.00a9f460@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Dec 2000 04:45:40 +1100 To: Robert Elz From: Geoff Huston Subject: Re: Addresses or routing... Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <20207.977198901@mundamutti.cs.mu.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk At 12/19/00 03:08 PM +1100, Robert Elz wrote: > Date: Tue, 19 Dec 2000 14:15:48 +1100 > From: Geoff Huston > Message-ID: <4.3.2.7.2.20001219141411.00acb750@jumble.telstra.net> > > | That's right - the address issues are, today, not > | really a pressing issue > >If you're a backbone type ISP, and your concern is managing the routers >in the backbone, that's probably true. > >On the other hand, if you're an end user, forced unwillingly into using >NAT because your ISP won't (or can't) give you sufficient address space >to number all your systems, then the address issues are pressing... >(Aside, please don't turn this into a NAT vs anti-NAT debate, I'm not >claiming that all users of NAT are unwilling users, just that some are). If there is a forcing function regarding address space availability, then the pointy end of the stick is the address allocation policies of the Regional Internet Registries. We have built a large global process around provider aggregation and the perceived shortage of IPv4 addresses as an outcome of the last passs of ROAD work at the start of the nineties. At the time we concentrated of provider-based hierarchies as the scaling tool in both routing and addressing. One way to look at today is as an outcome of these policies: - Provider-based address allocation hierarchies have increased the effort required to secure public address space. This is a contributing factor in the very widespread use of NAT technologies - Provider-based routing is no longer matching the increasingly dense interconnection topology, nor the requirements for reliaibility and resiliency through multi-homing, nor the requirements for traffic- engineering across the multiple connections. Instead advertisements of a network's address space is advertised globally and not agggregated in the next 'up' provider's domain. So the address allocation policies we've used through the nineties are now not an accurate reflection of the network and we see NAT, Multihoming, etc now becoming quite commonplace in the network. Should we attempt to re-impose provider-based hiararchies again? Should we look to other deployment models and attempt to identify associated allocation policies to match these models? From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 09:54:21 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA11093; Wed, 20 Dec 2000 09:54:21 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJMqqG03232 for deliver-b-i-au; Wed, 20 Dec 2000 09:52:52 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJMql503229 for ; Wed, 20 Dec 2000 09:52:47 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id SA08552; Wed, 20 Dec 2000 05:33:43 +1100 (from huitema@exchange.microsoft.com) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mumnunah.cs.mu.OZ.AU with ESMTP id FAA08634; Wed, 20 Dec 2000 05:33:36 +1100 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 19 Dec 2000 09:25:08 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 19 Dec 2000 09:25:50 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Tue, 19 Dec 2000 09:25:50 -0800 Subject: RE: Addresses or routing... Date: Tue, 19 Dec 2000 08:42:59 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Addresses or routing... Thread-Index: AcBp0IxPICx1G9y8R6a7Me1SNumRCwABousQ From: "Christian Huitema" To: "Robert Elz" , "Frank Kastenholz" Content-Class: urn:content-classes:message X-Mimeole: Produced By Microsoft Exchange V6.0.4604.0 Cc: X-Originalarrivaltime: 19 Dec 2000 17:25:50.0459 (UTC) FILETIME=[BB6F2CB0:01C069E0] Precedence: bulk Another source for the number of addresses in use is "http://www.netsizer.com", which provides a "real time" estimate of the number of addresses declared in "in-addr.arpa." This is in theory a subset of the routed address space declared in the BGP tables. According to the Netsizer, there would be about 98M addresses in use today, compared to about 68M a year ago -- a year upon year growth of about 43%.=20 For those who like statistical games, an exponential curve best fit on the Netsizer data from the last three years predict that we hit the 4 billions mark by mid 2009. Obviously, if you believe that you can extrapolate three years of data 9 years forward, you need to revisit your maths books -- but the same could be say about trying to extrapolate BGP data 20 years forward. The safest prediction is that we will never reach the 4 billions mark. What we have seen at work since 1992 is a "feedback control loop". As we near the mark, the conditions for getting addresses get more and more stringent, so that the growth is slowed. These more stringent conditions in effect thwart the growth of the Internet, by making it harder to deploy new applications, in particular peer-to-peer applications in which "every computer is a server." The rationale for moving to a larger address space is precisely to unleash these new applications. The recent evolution of the BGP tables shows that there is no direct correlation between the size of the address space and the size of the routing tables. Arguably, the main factors behind the growth of the BGP tables are multi-homing and traffic engineering. Changing from IPv4 to IPv6 means that the "atom" of multihoming changes from the /20 v4-natted space of a large site to the /48 v6-direct space of the same site. If everything else remains the same, the economic forces that push more networks in the BGP tables today will continue moving more v6 sites into the BGP tables tomorrow.=20 -- Christian Huitema From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 09:54:36 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA10837; Wed, 20 Dec 2000 09:54:36 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJMr2C03246 for deliver-b-i-au; Wed, 20 Dec 2000 09:53:02 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJMqu503241 for ; Wed, 20 Dec 2000 09:52:56 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id SA08523; Wed, 20 Dec 2000 05:13:40 +1100 (from gih@telstra.net) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by mumnunah.cs.mu.OZ.AU with ESMTP id FAA08138 for ; Wed, 20 Dec 2000 05:13:38 +1100 (EST) Received: from tecra.telstra.net ([203.10.60.4]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id FAA69068 for ; Wed, 20 Dec 2000 05:12:21 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001220050257.00ae2430@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Dec 2000 05:12:28 +1100 To: Big-Internet@munnari.OZ.AU From: Geoff Huston Subject: Re: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) In-Reply-To: References: <038701c06993$32689e80$050110ac@poole.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk At 12/19/00 06:47 AM -0800, Randy Bush wrote: > >>> I suppose somebody has to bite the bullet and ask the obvious stupid > >>> question: why are we seeing such a growth in /24's? Nearly 15% in just > >>> over 4 months? Something is going substantially wrong. > > > > Because there are a lot of careless people announcing 256 /24's thinking > > that such a strategy would bring them some benefit. > > > > A brief analysis of the last Tony Bates' CIDR report shows that we could > > have 70000 prefixes today very easily - just a bit of tidying up work has > > to be done. > >as the reports being shoved in everybody's face seem to do little good, >perhaps it is time to filter a bit more aggressively to get the message >through. [cc list trimmed back down to the list] Filtering aggressively may work - or it may just isolate you. Looking at the AS paths of various routes, prefix length filtering is simply not a common practice these days. Now you may want to use prefix filters - but the downside is that you would be blind to the fine-grained policies that are becoming quite common in the BGP table. This might not be a benefit, particularly if customers start to use a "do you prefix filter?" as one of their criteria in selecting a provider in the sense of "no = good, yes = bad". If you believe that there are 30,000 routing entries that are removable _without altering policy in any way_ then I would like to see the report that details this case by case. What is accurate to say is that there are some 40,440 (or so) advertisements that are more specific advertisements of existing aggregates. However only 5,475 (or so) of these are a policy match in terms of AS path. Even this number does not take into account a match of other attributes that may have been attached to the route advertisement. So if we can eliminate 30,000 routes and leave routing policy _unaltered_, please show me the code and show me the report (and, no, that level of detail is not covered in Tony's report). From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 09:54:36 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA11157; Wed, 20 Dec 2000 09:54:36 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBJMqxK03244 for deliver-b-i-au; Wed, 20 Dec 2000 09:52:59 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBJMqs503238 for ; Wed, 20 Dec 2000 09:52:54 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id SA08352; Wed, 20 Dec 2000 05:04:57 +1100 (from gih@telstra.net) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by mumnunah.cs.mu.OZ.AU with ESMTP id FAA08007 for ; Wed, 20 Dec 2000 05:04:55 +1100 (EST) Received: from tecra.telstra.net ([203.10.60.4]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id FAA67657; Wed, 20 Dec 2000 05:02:19 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001220045656.00b0de60@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Dec 2000 05:02:25 +1100 To: Kurt Erik Lindqvist From: Geoff Huston Subject: Re: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) Cc: Big-Internet@munnari.OZ.AU In-Reply-To: References: <4.3.2.7.2.20001220041539.00ac62a0@jumble.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk At 12/19/00 06:44 PM +0100, Kurt Erik Lindqvist wrote: > > > > is not correct, as it neglects to take into account the use of > specifics in > > > > local traffic engineering applications. > > > > > >I thought local traffic engineering applications where just that - local. > > > > If only that were true. > > > > A "problem" with BGP is that there are a paucity of commonly defined > > attributes, and often the only settings you have are "neighbor" > > (No Export) and "global". Now if you want to affect path selection > > of your neighbor's neighbor (and my observation is that this is > > quite common) then you turn on the global switch and _everyone_ > > gets to see it. > >The question here is ofcourse why would you? What is it that you need to >announce longer (and more) prefixes for that you can't do with other >methods (like chaning your upstream)? "chaning"? Is this a typo? I'm sorry I don't understand. Let me respond to "why would you"... Because of the differing way in which various providers do route selection, of of the most certain way to balance incoming traffic on multiple connections (multi-homed) is to announce an encompassing aggregate on both (all) connections, and then announce a set of more specific advertisements down each connection. The aggregate ensures mutual backup and the specifics allow you to change the amount of traffic passed along each connection. You can change the traffic balance by altering the specifics advertised along each connection. It relies on the universal use of the routing policy of preferring more specific routes as the first decision point in route selection. ugly? possibly. effective? very. From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 12:10:33 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id BA13507; Wed, 20 Dec 2000 12:10:33 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBK18BD03522 for deliver-b-i-au; Wed, 20 Dec 2000 12:08:11 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBK187W03519 for ; Wed, 20 Dec 2000 12:08:08 +1100 (EST) Received: from unknown (because of University of Melbourne policy) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id AA13187; Wed, 20 Dec 2000 11:46:22 +1100 (from jnc@ginger.lcs.mit.edu) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id TAA27648; Tue, 19 Dec 2000 19:43:47 -0500 Date: Tue, 19 Dec 2000 19:43:47 -0500 From: "J. Noel Chiappa" Message-Id: <200012200043.TAA27648@ginger.lcs.mit.edu> To: Big-Internet@munnari.OZ.AU Subject: Re: Addresses or routing... Cc: gih@telstra.net, jnc@ginger.lcs.mit.edu Precedence: bulk > From: Geoff Huston > Provider-based I have always disliked, and now really hate, the term "provider-based", because it can easily sounds like it's policy-driven. A far better term is "connectivity-based", which emphasizes the underlying technical fundamental - that for scalable routing, you need aggregable addresses, and that aggregation has to be based on the real connection topology. > routing is no longer matching the increasingly dense interconnection > topology, nor the requirements for reliaibility and resiliency through > multi-homing ... Instead advertisements of a network's address space is > advertised globally and not agggregated in the next 'up' provider's > domain. Now you've put your finger on the *real* problem. It's not "provider"-based addressing, but the lack of better aggregation tools. > we see .. Multihoming, etc now becoming quite commonplace in the > network. Should we attempt to re-impose provider-based hiararchies > again? We have no choice, for fundamental technical reasons, other than to use "provider"-based addressing. But that doesn't meant the paths selected have to be hierarchical - but we do have to provide aggregation tools. Noel From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 19:21:09 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id IA18692; Wed, 20 Dec 2000 19:21:09 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBK8Jda03775 for deliver-b-i-au; Wed, 20 Dec 2000 19:19:39 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBK8JaF03772 for ; Wed, 20 Dec 2000 19:19:36 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id IA18287; Wed, 20 Dec 2000 19:09:05 +1100 (from randy@psg.com) Received: from roam.psg.com (mg-206191146-20.ricochet.net [206.191.146.20]) by mumnunah.cs.mu.OZ.AU with ESMTP id TAA02174 for ; Wed, 20 Dec 2000 19:08:44 +1100 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 148cLI-0008Z6-00; Tue, 19 Dec 2000 22:03:12 -0800 From: Randy Bush Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Geoff Huston Cc: Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) References: <038701c06993$32689e80$050110ac@poole.ch> <4.3.2.7.2.20001220050257.00ae2430@jumble.telstra.net> Message-Id: Date: Tue, 19 Dec 2000 22:03:12 -0800 Precedence: bulk > So if we can eliminate 30,000 routes and leave routing policy _unaltered_, > please show me the code and show me the report as routing on today's internet is a horrifying disaster, leaving it unaltered is not necessarily a benefit. let's face it. bgp is a disaster. a cultural accident stopped internet routing architctural progress years ago and we have been patching and hacking to compensate for the mess ever since. leaving routing policy unaltered is a non-goal. leaving routing architecture unaltered is a non-goal. it is time to face it and fix it. [ and no, mpls is not the answer ] randy From owner-Big-Internet@murtoa.cs.mu.OZ.AU Wed Dec 20 20:50:17 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA19299; Wed, 20 Dec 2000 20:50:17 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBK9mhW03840 for deliver-b-i-au; Wed, 20 Dec 2000 20:48:43 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBK9meW03835 for ; Wed, 20 Dec 2000 20:48:40 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA19279; Wed, 20 Dec 2000 20:31:40 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mumnunah.cs.mu.OZ.AU with SMTP id UAA02834 for ; Wed, 20 Dec 2000 20:31:34 +1100 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 20 Dec 2000 09:28:33 +0000 To: Randy Bush Cc: Geoff Huston , Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) In-Reply-To: Your message of "Tue, 19 Dec 2000 22:03:12 PST." Date: Wed, 20 Dec 2000 09:28:32 +0000 Message-Id: <1270.977304512@cs.ucl.ac.uk> From: Jon Crowcroft Precedence: bulk In message , Randy Bush typed: >>leaving routing architecture unaltered is a non-goal. it is time to face >>it and fix it. [ and no, mpls is not the answer ] randy hmmm - well MPLS is a shim between legacy IPv4 and legacy link layers that switch (virtual path) so since MPLS is so popular with router vendors and allegedly with some operators, then why not just re-specify the label to be OUTISIDE the IPv4 header - i.e. use it as part of the IPv6 routing pre-fix (no, NOT the flow id) - then we have lots of people who say its ideal technology - we can use the current v4 address as local routing hint, the mac address as a EID and the mpls label as the rest of the address and voila - no need for mpls shim header saving liots of MTU, no need to worry about confusing renumbering at sites and all the aggregation you want according to the 123 mpls drafts..... of coruse there's a few little problems left like inter-domain and multihomeing which mpls, v4 and v6 seem to have all overlooked, but hey, at least we saved all those mpls WG docs fro mthe trash can :-) cheers jon From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 06:19:13 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id TA26085; Thu, 21 Dec 2000 06:19:13 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKJHDx05362 for deliver-b-i-au; Thu, 21 Dec 2000 06:17:13 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKJH9H05359 for ; Thu, 21 Dec 2000 06:17:09 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id PA21792; Thu, 21 Dec 2000 02:33:25 +1100 (from kurtis@kpnqwest.net) Received: from calvin.eunet.se (calvin.eunet.se [195.43.226.66]) by mumnunah.cs.mu.OZ.AU with ESMTP id CAA06362; Thu, 21 Dec 2000 02:33:12 +1100 (EST) Received: from calvin.eunet.se (calvin.eunet.se [195.43.226.66]) by calvin.eunet.se (8.9.3/8.9.3) with ESMTP id QAA07690; Wed, 20 Dec 2000 16:29:07 +0100 (MET) Date: Wed, 20 Dec 2000 16:29:07 +0100 (MET) From: Kurt Erik Lindqvist X-Sender: kurtis@calvin.eunet.se Reply-To: kurtis@kpnqwest.net To: Geoff Huston Cc: Robert Elz , Big-Internet@munnari.OZ.AU Subject: Re: 2x32 In-Reply-To: <4.3.2.7.2.20001220042838.00ad3cc0@jumble.telstra.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > And here's where I start to wonder - what it bandwidth were so cheap that > _every_ > ISP in the world and _every_ major "I'm just so important" customer had a > link to > Mae-Somewhere and had a co-located router there. Would this hierarchical model > of routing work across the very dense interconnection mesh of Mae-Somewhere? Bandwidth is cheap. Peering agreements are not. But to look at the question, I don't think BGP is scaling very well now considering the convergence times. I don't think that a setup with even more peers will make it more stable. I am not an exper at this, but I would suspect that longer paths is better than many peers. - kurtis - Kurt Erik Lindqvist Kurtis.Lindqvist@KPNQwest.SE KPNQwest Sweden @ The speed of light http://www.kpnqwest.se PO Box 23163 S-10435 Stockholm From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 06:19:17 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id TA26390; Thu, 21 Dec 2000 06:19:17 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKJHdp05367 for deliver-b-i-au; Thu, 21 Dec 2000 06:17:39 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKJHWH05364 for ; Thu, 21 Dec 2000 06:17:33 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id PA23624; Thu, 21 Dec 2000 02:08:43 +1100 (from brian@hursley.ibm.com) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by mumnunah.cs.mu.OZ.AU with ESMTP id CAA06013 for ; Thu, 21 Dec 2000 02:08:38 +1100 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id HAA48354; Wed, 20 Dec 2000 07:00:56 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA27158; Wed, 20 Dec 2000 07:05:55 -0800 Message-Id: <3A40CA84.D7295A0F@hursley.ibm.com> Date: Wed, 20 Dec 2000 09:04:36 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr Mime-Version: 1.0 To: Cyndi Jung Cc: Matt Crawford , Big-Internet@munnari.OZ.AU Subject: Re: 2x32 References: <3.0.6.32.20001219090943.02b2e2c0@mailhost.ewd.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk And there was I hoping that we wouldn't see anything longer than /16 in the default-free zone. If we see /48s the way we are seeing IPv4 /24s today, we will be in deep trouble.We **really** need to fix the multihoming (for which there is now a separate list). Brian Cyndi Jung wrote: > > I think this is assuming the longest prefix that makes it into the non-default > routing tables is a /48. > > Cyndi > > At 08:37 AM 12/19/00 -0600, Matt Crawford wrote: > >> full IPv4 host routes are identical to the space reserved for routing IPv6 > >> addresses. The IPv6 space is "carved" up with the last 64 bits as MAC > >> address and the first 32 as "address family", leaving the second 32-bit > chunk > >> to define routing. > > > >Say what? > > > > From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 06:19:24 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id TA26574; Thu, 21 Dec 2000 06:19:24 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKJI0x05372 for deliver-b-i-au; Thu, 21 Dec 2000 06:18:00 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKJHvH05369 for ; Thu, 21 Dec 2000 06:17:57 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id QA23959; Thu, 21 Dec 2000 03:00:25 +1100 (from kurtis@kpnqwest.net) Received: from calvin.eunet.se (calvin.eunet.se [195.43.226.66]) by mumnunah.cs.mu.OZ.AU with ESMTP id DAA06758 for ; Thu, 21 Dec 2000 03:00:19 +1100 (EST) Received: from calvin.eunet.se (calvin.eunet.se [195.43.226.66]) by calvin.eunet.se (8.9.3/8.9.3) with ESMTP id QAA09464; Wed, 20 Dec 2000 16:56:50 +0100 (MET) Date: Wed, 20 Dec 2000 16:56:50 +0100 (MET) From: Kurt Erik Lindqvist X-Sender: kurtis@calvin.eunet.se Reply-To: Kurt Erik Lindqvist To: Geoff Huston Cc: Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) In-Reply-To: <4.3.2.7.2.20001220045656.00b0de60@jumble.telstra.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > > > A "problem" with BGP is that there are a paucity of commonly defined > > > attributes, and often the only settings you have are "neighbor" > > > (No Export) and "global". Now if you want to affect path selection > > > of your neighbor's neighbor (and my observation is that this is > > > quite common) then you turn on the global switch and _everyone_ > > > gets to see it. > > > >The question here is ofcourse why would you? What is it that you need to > >announce longer (and more) prefixes for that you can't do with other > >methods (like chaning your upstream)? > > > "chaning"? Is this a typo? I'm sorry I don't understand. Typo. Should be changing. > Let me respond to "why would you"... > > Because of the differing way in which various providers do route selection, > of of the most certain way to balance incoming traffic on multiple > connections (multi-homed) is to announce an encompassing aggregate > on both (all) connections, and then announce a set of more specific > advertisements down each connection. The aggregate ensures mutual backup > and the specifics allow you to change the amount of traffic passed along each > connection. You can change the traffic balance by altering the specifics > advertised along each connection. It relies on the universal use of the > routing policy of preferring more specific routes as the first decision > point in route selection. But as I understand your example above this is still for local load balancing withing your own network? For interfacing with your upstreams routing your upstream should have approriate communities setup for you to use. I still don't see this as a valid reason to swap the routing table. - kurtis - Kurt Erik Lindqvist Kurtis.Lindqvist@KPNQwest.SE KPNQwest Sweden @ The speed of light http://www.kpnqwest.se PO Box 23163 S-10435 Stockholm From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 06:19:48 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id TA24815; Thu, 21 Dec 2000 06:19:48 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKJIOX05377 for deliver-b-i-au; Thu, 21 Dec 2000 06:18:24 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKJILH05374 for ; Thu, 21 Dec 2000 06:18:21 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id SA25807; Thu, 21 Dec 2000 05:27:37 +1100 (from gih@telstra.net) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by mumnunah.cs.mu.OZ.AU with ESMTP id FAA09668 for ; Thu, 21 Dec 2000 05:27:34 +1100 (EST) Received: from tecra.telstra.net ([203.10.60.4]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id FAA26362; Thu, 21 Dec 2000 05:26:02 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001221051332.00b02bb0@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Dec 2000 05:15:25 +1100 To: kurtis@kpnqwest.net From: Geoff Huston Subject: Re: 2x32 Cc: Big-Internet@munnari.OZ.AU In-Reply-To: References: <4.3.2.7.2.20001220042838.00ad3cc0@jumble.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk At 12/20/00 04:29 PM +0100, Kurt Erik Lindqvist wrote: > > And here's where I start to wonder - what it bandwidth were so cheap that > > _every_ > > ISP in the world and _every_ major "I'm just so important" customer had a > > link to > > Mae-Somewhere and had a co-located router there. Would this > hierarchical model > > of routing work across the very dense interconnection mesh of > Mae-Somewhere? > >Bandwidth is cheap. Peering agreements are not. But to look at the >question, I don't think BGP is scaling very well now considering the >convergence times. I don't think that a setup with even more peers will >make it more stable. I am not an exper at this, but I would suspect that >longer paths is better than many peers. longer paths be better than many peers, but what is visible in the traces of the BGP table is a trend towards many peers rather than longer paths. This is not surprising considering the changes in the unit cost of communications bearers. I agree this is a stability concern for BGP4 as we know it. From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 06:20:29 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id TA26048; Thu, 21 Dec 2000 06:20:29 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKJJ3c05382 for deliver-b-i-au; Thu, 21 Dec 2000 06:19:03 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKJJ0H05379 for ; Thu, 21 Dec 2000 06:19:00 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id SA26052; Thu, 21 Dec 2000 05:27:42 +1100 (from gih@telstra.net) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by mumnunah.cs.mu.OZ.AU with ESMTP id FAA09672 for ; Thu, 21 Dec 2000 05:27:40 +1100 (EST) Received: from tecra.telstra.net ([203.10.60.4]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id FAA26365; Thu, 21 Dec 2000 05:26:06 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001221051555.00b163d0@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Dec 2000 05:24:29 +1100 To: Kurt Erik Lindqvist From: Geoff Huston Subject: Re: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) Cc: Big-Internet@munnari.OZ.AU In-Reply-To: References: <4.3.2.7.2.20001220045656.00b0de60@jumble.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk > >But as I understand your example above this is still for local load >balancing withing your own network? For interfacing with your upstreams >routing your upstream should have approriate communities setup for you to >use. I still don't see this as a valid reason to swap the routing table. Try it. The first goal is that of attempting to bias the traffic flows of your immediate neighbors, but often you still end up with a large clump of traffic that simply will not balance across multiple circuits (hint - look at which AS's originate the greatest number of routes). If you want to balance this traffic across multiple circuits then you have to extend your traffic preferences across multiple upstream AS's. Communities, as we know them, don't work. Hence you traffic engineer using BGP and more specific routes. But I'm NOT trying to explain what folk could do. The essential observation is a rapid rise in the number of short prefixes in the routing table. The next order question is WHY? Some folk are saying "Its just that many folk who configure BGP sessions are dumb, ignorant, or both'. I'm saying "Thats probably not right - lets see if there are a good reasons why this is going on, and then see if we can find any supportive evidence in the BGP tables to confirm that this is happening." If you have a better method of understanding why the BGP table is behaving that way its is, I'd be pleased to hear it, as I've no particular desire to delve into the practices of multi-homing multi-AS traffic engineering on this list, other than to see if this is a contributory factor in the BGP table's growth. From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 08:19:19 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id VA26216; Thu, 21 Dec 2000 08:19:19 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKLHhY05539 for deliver-b-i-au; Thu, 21 Dec 2000 08:17:43 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKLHdE05536 for ; Thu, 21 Dec 2000 08:17:40 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id UA26878; Thu, 21 Dec 2000 07:04:12 +1100 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by mumnunah.cs.mu.OZ.AU with ESMTP id HAA10592 for ; Thu, 21 Dec 2000 07:04:08 +1100 (EST) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id PAA00693; Wed, 20 Dec 2000 15:02:48 -0500 Date: Wed, 20 Dec 2000 15:02:48 -0500 From: "J. Noel Chiappa" Message-Id: <200012202002.PAA00693@ginger.lcs.mit.edu> To: Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE Cc: gih@telstra.net, jnc@ginger.lcs.mit.edu Precedence: bulk > From: Geoff Huston > If you want to balance this traffic across multiple circuits then you > have to extend your traffic preferences across multiple upstream AS's. > ... Some folk are saying "Its just that many folk who configure BGP > sessions are dumb, ignorant, or both'. Clearly, that's not the problem; which is, rather, that people are trying to do things that we don't currently provide good tools for. So they use whatever tools they do have - and surprise, surprise, when those tools are used to do things they weren't designed to do, they have unpleasant side-effects. I must confess that splitting incoming traffic evenly across a number of topologically disparate links is not an objective (for a routing architecture) that I've given much thought to. I'll have to ponder it for a while, and see what's the best approach I can come up with. (At a first glance, it looks somewhat harder than multi-homing.) Noel From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 08:19:22 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id VA27700; Thu, 21 Dec 2000 08:19:22 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKLHwR05549 for deliver-b-i-au; Thu, 21 Dec 2000 08:17:58 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKLHsE05546 for ; Thu, 21 Dec 2000 08:17:54 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id TA26246; Thu, 21 Dec 2000 06:33:06 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: from srv16.persocom.com.br (srv16.persocom.com.br [200.199.233.16]) by mumnunah.cs.mu.OZ.AU with ESMTP id GAA10286; Thu, 21 Dec 2000 06:32:57 +1100 (EST) Received: from srv2.persocom.com.br ([200.199.233.2]) by srv16.persocom.com.br (Post.Office MTA v3.5.3 release 223 ID# 0-55032U2500L250S0V35) with ESMTP id br; Wed, 20 Dec 2000 17:31:38 -0200 Received: from srv16.persocom.com.br ([200.199.233.16]) by srv2.persocom.com.br (post.office MTA v2.0 0813 ID# 0-12327) with ESMTP id AAA176 for ; Wed, 20 Dec 2000 17:31:36 -0200 Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by srv16.persocom.com.br (Post.Office MTA v3.5.3 release 223 ID# 0-55032U2500L250S0V35) with ESMTP id br for ; Wed, 20 Dec 2000 17:31:31 -0200 Received: by murtoa.cs.mu.OZ.AU id eBKJKZL05454 for deliver-b-i-eu; Thu, 21 Dec 2000 06:20:35 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKJH9H05359 for ; Thu, 21 Dec 2000 06:17:09 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id PA21792; Thu, 21 Dec 2000 02:33:25 +1100 (from kurtis@kpnqwest.net) Received: from calvin.eunet.se (calvin.eunet.se [195.43.226.66]) by mumnunah.cs.mu.OZ.AU with ESMTP id CAA06362; Thu, 21 Dec 2000 02:33:12 +1100 (EST) Received: from calvin.eunet.se (calvin.eunet.se [195.43.226.66]) by calvin.eunet.se (8.9.3/8.9.3) with ESMTP id QAA07690; Wed, 20 Dec 2000 16:29:07 +0100 (MET) Date: Wed, 20 Dec 2000 16:29:07 +0100 (MET) From: Kurt Erik Lindqvist X-Sender: kurtis@calvin.eunet.se Reply-To: kurtis@kpnqwest.net To: Geoff Huston Cc: Robert Elz , Big-Internet@munnari.OZ.AU Subject: Re: 2x32 In-Reply-To: <4.3.2.7.2.20001220042838.00ad3cc0@jumble.telstra.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > And here's where I start to wonder - what it bandwidth were so cheap that > _every_ > ISP in the world and _every_ major "I'm just so important" customer had a > link to > Mae-Somewhere and had a co-located router there. Would this hierarchical model > of routing work across the very dense interconnection mesh of Mae-Somewhere? Bandwidth is cheap. Peering agreements are not. But to look at the question, I don't think BGP is scaling very well now considering the convergence times. I don't think that a setup with even more peers will make it more stable. I am not an exper at this, but I would suspect that longer paths is better than many peers. - kurtis - Kurt Erik Lindqvist Kurtis.Lindqvist@KPNQwest.SE KPNQwest Sweden @ The speed of light http://www.kpnqwest.se PO Box 23163 S-10435 Stockholm From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 08:19:21 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id VA27895; Thu, 21 Dec 2000 08:19:21 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKLHmH05544 for deliver-b-i-au; Thu, 21 Dec 2000 08:17:48 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKLHhE05541 for ; Thu, 21 Dec 2000 08:17:43 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id UA26791; Thu, 21 Dec 2000 07:08:54 +1100 (from cmj@3Com.com) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by mumnunah.cs.mu.OZ.AU with ESMTP id HAA10636 for ; Thu, 21 Dec 2000 07:08:47 +1100 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id MAA20982; Wed, 20 Dec 2000 12:05:12 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id MAA15684; Wed, 20 Dec 2000 12:05:11 -0800 (PST) Received: from cyndi (vpn-246.nsd.3com.com [129.213.205.246]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id MAA22270; Wed, 20 Dec 2000 12:05:09 -0800 (PST) Message-Id: <3.0.6.32.20001220120928.00ad8a60@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 20 Dec 2000 12:09:28 -0800 To: Brian E Carpenter From: Cyndi Jung Subject: Re: 2x32 Cc: Matt Crawford , Big-Internet@munnari.OZ.AU In-Reply-To: <3A40CA84.D7295A0F@hursley.ibm.com> References: <3.0.6.32.20001219090943.02b2e2c0@mailhost.ewd.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Well, the first 16 bits are administrative, and the bits 49-64 are "site specific", so *at worst* there are 32 bits to route on IF there is nothing longer than a /48 in the BGP tables. My 6Bone node advertises a /24, and really only 8 bits have any topological meaning, but of course need the context of the first 16 bits. Cyndi At 09:04 AM 12/20/00 -0600, Brian E Carpenter wrote: >And there was I hoping that we wouldn't see anything longer than /16 >in the default-free zone. If we see /48s the way we are seeing >IPv4 /24s today, we will be in deep trouble.We **really** need to >fix the multihoming (for which there is now a separate list). > > Brian > >Cyndi Jung wrote: >> >> I think this is assuming the longest prefix that makes it into the non-default >> routing tables is a /48. >> >> Cyndi >> >> At 08:37 AM 12/19/00 -0600, Matt Crawford wrote: >> >> full IPv4 host routes are identical to the space reserved for routing IPv6 >> >> addresses. The IPv6 space is "carved" up with the last 64 bits as MAC >> >> address and the first 32 as "address family", leaving the second 32-bit >> chunk >> >> to define routing. >> > >> >Say what? >> > >> > > > From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 08:19:37 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id VA28089; Thu, 21 Dec 2000 08:19:37 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKLIDt05554 for deliver-b-i-au; Thu, 21 Dec 2000 08:18:13 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKLI9E05551 for ; Thu, 21 Dec 2000 08:18:09 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id TA26520; Thu, 21 Dec 2000 06:33:10 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: from srv16.persocom.com.br (srv16.persocom.com.br [200.199.233.16]) by mumnunah.cs.mu.OZ.AU with ESMTP id GAA10295; Thu, 21 Dec 2000 06:33:05 +1100 (EST) Received: from srv2.persocom.com.br ([200.199.233.2]) by srv16.persocom.com.br (Post.Office MTA v3.5.3 release 223 ID# 0-55032U2500L250S0V35) with ESMTP id br; Wed, 20 Dec 2000 17:31:46 -0200 Received: from srv16.persocom.com.br ([200.199.233.16]) by srv2.persocom.com.br (post.office MTA v2.0 0813 ID# 0-12327) with ESMTP id AAA212 for ; Wed, 20 Dec 2000 17:31:45 -0200 Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by srv16.persocom.com.br (Post.Office MTA v3.5.3 release 223 ID# 0-55032U2500L250S0V35) with ESMTP id br for ; Wed, 20 Dec 2000 17:31:41 -0200 Received: by murtoa.cs.mu.OZ.AU id eBKJKUF05444 for deliver-b-i-eu; Thu, 21 Dec 2000 06:20:30 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKJHWH05364 for ; Thu, 21 Dec 2000 06:17:33 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id PA23624; Thu, 21 Dec 2000 02:08:43 +1100 (from brian@hursley.ibm.com) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by mumnunah.cs.mu.OZ.AU with ESMTP id CAA06013 for ; Thu, 21 Dec 2000 02:08:38 +1100 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id HAA48354; Wed, 20 Dec 2000 07:00:56 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA27158; Wed, 20 Dec 2000 07:05:55 -0800 Message-Id: <3A40CA84.D7295A0F@hursley.ibm.com> Date: Wed, 20 Dec 2000 09:04:36 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr Mime-Version: 1.0 To: Cyndi Jung Cc: Matt Crawford , Big-Internet@munnari.OZ.AU Subject: Re: 2x32 References: <3.0.6.32.20001219090943.02b2e2c0@mailhost.ewd.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk And there was I hoping that we wouldn't see anything longer than /16 in the default-free zone. If we see /48s the way we are seeing IPv4 /24s today, we will be in deep trouble.We **really** need to fix the multihoming (for which there is now a separate list). Brian Cyndi Jung wrote: > > I think this is assuming the longest prefix that makes it into the non-default > routing tables is a /48. > > Cyndi > > At 08:37 AM 12/19/00 -0600, Matt Crawford wrote: > >> full IPv4 host routes are identical to the space reserved for routing IPv6 > >> addresses. The IPv6 space is "carved" up with the last 64 bits as MAC > >> address and the first 32 as "address family", leaving the second 32-bit > chunk > >> to define routing. > > > >Say what? > > > > From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 08:33:32 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id VA27984; Thu, 21 Dec 2000 08:33:32 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKLW7S05732 for deliver-b-i-au; Thu, 21 Dec 2000 08:32:07 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKLW3705728 for ; Thu, 21 Dec 2000 08:32:03 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id UA26808; Thu, 21 Dec 2000 07:42:36 +1100 (from gih@telstra.net) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by mumnunah.cs.mu.OZ.AU with ESMTP id HAA10908 for ; Thu, 21 Dec 2000 07:42:35 +1100 (EST) Received: from tecra.telstra.net ([203.10.60.4]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id HAA29165; Thu, 21 Dec 2000 07:41:11 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001221073416.00b08350@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Dec 2000 07:37:22 +1100 To: "J. Noel Chiappa" From: Geoff Huston Subject: Re: AGGREGATE Cc: Big-Internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <200012202002.PAA00693@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk >I must confess that splitting incoming traffic evenly across a number of >topologically disparate links is not an objective (for a routing architecture) >that I've given much thought to. And for some people its what they do every day. > I'll have to ponder it for a while, and see >what's the best approach I can come up with. (At a first glance, it looks >somewhat harder than multi-homing.) We manage very well on the whole. The casualty is the BGP routing table. So yes, I agree we need to think about what tools are necessary to achieve inter-domain traffic engineering in a multi-homed environment. That was one of the points I was attempting to make in the Routing Area presentation. From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 08:33:28 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id VA28360; Thu, 21 Dec 2000 08:33:28 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKLVra05726 for deliver-b-i-au; Thu, 21 Dec 2000 08:31:53 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKLVm705723 for ; Thu, 21 Dec 2000 08:31:48 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id UA26791; Thu, 21 Dec 2000 07:08:54 +1100 (from cmj@3Com.com) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by mumnunah.cs.mu.OZ.AU with ESMTP id HAA10636 for ; Thu, 21 Dec 2000 07:08:47 +1100 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id MAA20982; Wed, 20 Dec 2000 12:05:12 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id MAA15684; Wed, 20 Dec 2000 12:05:11 -0800 (PST) Received: from cyndi (vpn-246.nsd.3com.com [129.213.205.246]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id MAA22270; Wed, 20 Dec 2000 12:05:09 -0800 (PST) Message-Id: <3.0.6.32.20001220120928.00ad8a60@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 20 Dec 2000 12:09:28 -0800 To: Brian E Carpenter From: Cyndi Jung Subject: Re: 2x32 Cc: Matt Crawford , Big-Internet@munnari.OZ.AU In-Reply-To: <3A40CA84.D7295A0F@hursley.ibm.com> References: <3.0.6.32.20001219090943.02b2e2c0@mailhost.ewd.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Well, the first 16 bits are administrative, and the bits 49-64 are "site specific", so *at worst* there are 32 bits to route on IF there is nothing longer than a /48 in the BGP tables. My 6Bone node advertises a /24, and really only 8 bits have any topological meaning, but of course need the context of the first 16 bits. Cyndi At 09:04 AM 12/20/00 -0600, Brian E Carpenter wrote: >And there was I hoping that we wouldn't see anything longer than /16 >in the default-free zone. If we see /48s the way we are seeing >IPv4 /24s today, we will be in deep trouble.We **really** need to >fix the multihoming (for which there is now a separate list). > > Brian > >Cyndi Jung wrote: >> >> I think this is assuming the longest prefix that makes it into the non-default >> routing tables is a /48. >> >> Cyndi >> >> At 08:37 AM 12/19/00 -0600, Matt Crawford wrote: >> >> full IPv4 host routes are identical to the space reserved for routing IPv6 >> >> addresses. The IPv6 space is "carved" up with the last 64 bits as MAC >> >> address and the first 32 as "address family", leaving the second 32-bit >> chunk >> >> to define routing. >> > >> >Say what? >> > >> > > > From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 08:50:37 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id VA28450; Thu, 21 Dec 2000 08:50:37 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKLmxb05796 for deliver-b-i-au; Thu, 21 Dec 2000 08:48:59 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKLmrN05791 for ; Thu, 21 Dec 2000 08:48:54 +1100 (EST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id VA27147; Thu, 21 Dec 2000 08:45:12 +1100 (from hostmaster@munnari.OZ.AU) From: Robert Elz To: Cyndi Jung Cc: Brian E Carpenter , Matt Crawford , Big-Internet@munnari.OZ.AU Subject: Re: 2x32 In-Reply-To: Your message of "Wed, 20 Dec 2000 12:09:28 -0800." <3.0.6.32.20001220120928.00ad8a60@mailhost.ewd.3com.com> Date: Thu, 21 Dec 2000 08:45:11 +1100 Message-Id: <13103.977348711@mundamutti.cs.mu.OZ.AU> Precedence: bulk Date: Wed, 20 Dec 2000 12:09:28 -0800 From: Cyndi Jung Message-ID: <3.0.6.32.20001220120928.00ad8a60@mailhost.ewd.3com.com> | Well, the first 16 bits are administrative, Huh? The top 3 bits are administrative. The next 13 are the TLA. That's where the 8K routing table size comes from. They're the bits you're routing using (in a backbone router, and according to the current plans anyway). But perhaps you are thinking of RFC2471 - the addresses currently being used across the 6bone, where the TLA is fixed (just one asigned for this purpose). The 6bone is being considered as a single IPv6 provider, if you're a 6bone (internal) router, then yes, sure, the top 16 bits will be fixed, and you're going to route on bits lower down the address. That's just the same as being a University of Melbourne router, where the top 16 bits of the IPv4 address are fixed (128.250) and routing is done using lesser significant bits of the address. But no-one on the true internet backbone is sver supposed to see any f that internal detail - in the v4 world, the 128.250 part is what is used for routing (until packets enter the local net), in IPv6 routing the TLA is used (until packets enter that transit provider's local net). Please don't assume that the 2471 addresses ae what should be being used globally once IPv6 escapes from the 6bone. kre From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 08:51:22 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id VA28096; Thu, 21 Dec 2000 08:51:22 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKLntm05806 for deliver-b-i-au; Thu, 21 Dec 2000 08:49:55 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKLnnU05801 for ; Thu, 21 Dec 2000 08:49:50 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id VA28770; Thu, 21 Dec 2000 08:48:11 +1100 (from brian@hursley.ibm.com) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by mumnunah.cs.mu.OZ.AU with ESMTP id IAA11575 for ; Thu, 21 Dec 2000 08:48:08 +1100 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA18250; Wed, 20 Dec 2000 13:40:23 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA32498; Wed, 20 Dec 2000 13:45:27 -0800 Message-Id: <3A4127EC.E7EB69B2@hursley.ibm.com> Date: Wed, 20 Dec 2000 15:43:08 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr Mime-Version: 1.0 To: Cyndi Jung Cc: Matt Crawford , Big-Internet@munnari.OZ.AU Subject: Re: 2x32 References: <3.0.6.32.20001219090943.02b2e2c0@mailhost.ewd.3com.com> <3.0.6.32.20001220120928.00ad8a60@mailhost.ewd.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Cyndi, TLAs are not supposed to be administrative. You are correct within the 6BONE or the subTLAs of course, but the real future is genuine TLAs. Ideally we would see 2**13 subTLAs and 2**13 TLAs in the default-free table, and nothing else (after the 6BONE goes away). I realise we don't live in an ideal world, and that the pre-condition for getting anywhere near the ideal is cracking the multihoming problem, i.e. find a way to keep those /48s local. Brian Cyndi Jung wrote: > > Well, the first 16 bits are administrative, and the bits 49-64 > are "site specific", so *at worst* there are 32 bits to route on IF there > is nothing longer than a /48 in the BGP tables. My 6Bone node advertises > a /24, and really only 8 bits have any topological meaning, but of course > need the context of the first 16 bits. > > Cyndi > > At 09:04 AM 12/20/00 -0600, Brian E Carpenter wrote: > >And there was I hoping that we wouldn't see anything longer than /16 > >in the default-free zone. If we see /48s the way we are seeing > >IPv4 /24s today, we will be in deep trouble.We **really** need to > >fix the multihoming (for which there is now a separate list). > > > > Brian > > > >Cyndi Jung wrote: > >> > >> I think this is assuming the longest prefix that makes it into the > non-default > >> routing tables is a /48. > >> > >> Cyndi > >> > >> At 08:37 AM 12/19/00 -0600, Matt Crawford wrote: > >> >> full IPv4 host routes are identical to the space reserved for routing > IPv6 > >> >> addresses. The IPv6 space is "carved" up with the last 64 bits as MAC > >> >> address and the first 32 as "address family", leaving the second 32-bit > >> chunk > >> >> to define routing. > >> > > >> >Say what? > >> > > >> > > > > > From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 09:00:14 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA10773; Thu, 21 Dec 2000 09:00:14 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKLwo305856 for deliver-b-i-au; Thu, 21 Dec 2000 08:58:50 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKLwk605853 for ; Thu, 21 Dec 2000 08:58:46 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id VA28917; Thu, 21 Dec 2000 08:51:34 +1100 (from brian@hursley.ibm.com) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by mumnunah.cs.mu.OZ.AU with ESMTP id IAA11646 for ; Thu, 21 Dec 2000 08:51:27 +1100 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA18362; Wed, 20 Dec 2000 13:43:46 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA27278; Wed, 20 Dec 2000 13:48:49 -0800 Message-Id: <3A4128B9.223045F4@hursley.ibm.com> Date: Wed, 20 Dec 2000 15:46:33 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr Mime-Version: 1.0 To: Geoff Huston Cc: Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) References: <4.3.2.7.2.20001220045656.00b0de60@jumble.telstra.net> <4.3.2.7.2.20001221051555.00b163d0@jumble.telstra.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk One way to find out why rational people did something is to ask them. Would it be possible to select a random bunch of recent /24 announcements, and ask the originating ISP "why did you do that?" (with a suitable reason for asking and a promise of anonymity)? Brian Geoff Huston wrote: > > > > >But as I understand your example above this is still for local load > >balancing withing your own network? For interfacing with your upstreams > >routing your upstream should have approriate communities setup for you to > >use. I still don't see this as a valid reason to swap the routing table. > > Try it. The first goal is that of attempting to bias the traffic > flows of your immediate neighbors, but often you still end up with a > large clump of traffic that simply will not balance across multiple > circuits (hint - look at which AS's originate the greatest number of > routes). If you want to balance this traffic across multiple circuits > then you have to extend your traffic preferences across multiple > upstream AS's. Communities, as we know them, don't work. Hence you > traffic engineer using BGP and more specific routes. > > But I'm NOT trying to explain what folk could do. The essential observation > is a rapid rise in the number of short prefixes in the routing table. The > next order question is WHY? Some folk are saying "Its just that many folk > who configure BGP sessions are dumb, ignorant, or both'. I'm saying "Thats > probably not right - lets see if there are a good reasons why this is > going on, and then see if we can find any supportive evidence in the > BGP tables to confirm that this is happening." > > If you have a better method of understanding why the BGP table is behaving > that way its is, I'd be pleased to hear it, as I've no particular desire > to delve into the practices of multi-homing multi-AS traffic engineering > on this list, other than to see if this is a contributory factor in the > BGP table's growth. From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 09:11:18 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA29065; Thu, 21 Dec 2000 09:11:18 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKM9oU05901 for deliver-b-i-au; Thu, 21 Dec 2000 09:09:50 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKM9kJ05897 for ; Thu, 21 Dec 2000 09:09:46 +1100 (EST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA28251; Thu, 21 Dec 2000 09:08:41 +1100 (from hostmaster@munnari.OZ.AU) From: Robert Elz To: Geoff Huston Cc: "J. Noel Chiappa" , Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE In-Reply-To: Your message of "Thu, 21 Dec 2000 07:37:22 +1100." <4.3.2.7.2.20001221073416.00b08350@jumble.telstra.net> Date: Thu, 21 Dec 2000 09:08:40 +1100 Message-Id: <13296.977350120@mundamutti.cs.mu.OZ.AU> Precedence: bulk Date: Thu, 21 Dec 2000 07:37:22 +1100 From: Geoff Huston Message-ID: <4.3.2.7.2.20001221073416.00b08350@jumble.telstra.net> Initially Geoff quoted Noel Chiappa... | >I must confess that splitting incoming traffic evenly across a number of | >topologically disparate links is not an objective (for a routing | >architecture) that I've given much thought to. | | And for some people its what they do every day. [another quote deleted]. | We manage very well on the whole. The casualty is the BGP routing table. 10 years ago, when the immediate problem was address space exhaustion the ("short term" anyway) solution was to come down hard on the end users, restrict the number of addresses available, and make them much harder to be portable. That had deliterious effects upon the end users (and aside from having to do some of the associated administrative work) comparatively little effect upon the core network. By using various other strategies (like NAT, as foul as it is) the end users managed to find ways to operate successfully (mostly successfully) despite the restrictions. Now the immediate problem is BGP routing table size - it may be that the ("short term" anyway) solution is going to have to be to simply come down hard on the core network this time, and prohibit (or at least severly restrict) the ability of the network operators to do such things as traffic engineering via the routing tables. I suspect that given such restrictions the network operators would manage to find ways to continue to operate - perhaps they might just install more bandwidth on the links that want to naturally attract more traffic, instead of polluting the routing table to push that traffic onto otherwise underutilised links. kre From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 09:44:45 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA28740; Thu, 21 Dec 2000 09:44:45 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKMhCq05972 for deliver-b-i-au; Thu, 21 Dec 2000 09:43:12 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKMh4X05967 for ; Thu, 21 Dec 2000 09:43:05 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA28769; Thu, 21 Dec 2000 09:37:15 +1100 (from cmj@3Com.com) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by mumnunah.cs.mu.OZ.AU with ESMTP id JAA12232 for ; Thu, 21 Dec 2000 09:36:16 +1100 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id OAA21568; Wed, 20 Dec 2000 14:32:57 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id OAA18450; Wed, 20 Dec 2000 14:32:57 -0800 (PST) Received: from cyndi ([139.87.12.246]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id OAA25065; Wed, 20 Dec 2000 14:32:56 -0800 (PST) Message-Id: <3.0.6.32.20001220143719.00a23c20@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 20 Dec 2000 14:37:19 -0800 To: Brian E Carpenter From: Cyndi Jung Subject: Re: 2x32 Cc: Matt Crawford , Big-Internet@munnari.OZ.AU In-Reply-To: <3A4127EC.E7EB69B2@hursley.ibm.com> References: <3.0.6.32.20001219090943.02b2e2c0@mailhost.ewd.3com.com> <3.0.6.32.20001220120928.00ad8a60@mailhost.ewd.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk So why do all the non-6Bone routes begin with 2001? Doesn't that identify the addressing authority (ARIN, RIPE, APNIC - I can't find quickly the authority). It doesn't seem like there will be many more addressing authorities at the top level - I don't expect a lot of different values for those first 16 bits. But evidently you have a different view of it. Cyndi At 03:43 PM 12/20/00 -0600, Brian E Carpenter wrote: >Cyndi, > >TLAs are not supposed to be administrative. You are correct within the >6BONE or the subTLAs of course, but the real future is genuine TLAs. Ideally >we would see 2**13 subTLAs and 2**13 TLAs in the default-free table, and >nothing else (after the 6BONE goes away). > >I realise we don't live in an ideal world, and that the pre-condition for getting >anywhere near the ideal is cracking the multihoming problem, i.e. find a way to >keep those /48s local. > > Brian > >Cyndi Jung wrote: >> >> Well, the first 16 bits are administrative, and the bits 49-64 >> are "site specific", so *at worst* there are 32 bits to route on IF there >> is nothing longer than a /48 in the BGP tables. My 6Bone node advertises >> a /24, and really only 8 bits have any topological meaning, but of course >> need the context of the first 16 bits. >> >> Cyndi >> >> At 09:04 AM 12/20/00 -0600, Brian E Carpenter wrote: >> >And there was I hoping that we wouldn't see anything longer than /16 >> >in the default-free zone. If we see /48s the way we are seeing >> >IPv4 /24s today, we will be in deep trouble.We **really** need to >> >fix the multihoming (for which there is now a separate list). >> > >> > Brian >> > >> >Cyndi Jung wrote: >> >> >> >> I think this is assuming the longest prefix that makes it into the >> non-default >> >> routing tables is a /48. >> >> >> >> Cyndi >> >> >> >> At 08:37 AM 12/19/00 -0600, Matt Crawford wrote: >> >> >> full IPv4 host routes are identical to the space reserved for routing >> IPv6 >> >> >> addresses. The IPv6 space is "carved" up with the last 64 bits as MAC >> >> >> address and the first 32 as "address family", leaving the second 32-bit >> >> chunk >> >> >> to define routing. >> >> > >> >> >Say what? >> >> > >> >> > >> > >> > > > From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 10:19:09 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id XA29470; Thu, 21 Dec 2000 10:19:09 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKNHj806017 for deliver-b-i-au; Thu, 21 Dec 2000 10:17:45 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKNHeG06012 for ; Thu, 21 Dec 2000 10:17:40 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id XA28561; Thu, 21 Dec 2000 10:12:20 +1100 (from bmanning@vacation.karoshi.com) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.4.20]) by mumnunah.cs.mu.OZ.AU with ESMTP id KAA12773 for ; Thu, 21 Dec 2000 10:12:14 +1100 (EST) From: bmanning@vacation.karoshi.com Received: (from bmanning@localhost) by vacation.karoshi.com (8.9.3/8.9.3) id XAA26266; Wed, 20 Dec 2000 23:00:47 GMT Message-Id: <200012202300.XAA26266@vacation.karoshi.com> Subject: Re: 2x32 To: cmj@3Com.COM (Cyndi Jung) Date: Wed, 20 Dec 2000 23:00:47 +0000 (UCT) Cc: brian@hursley.ibm.com (Brian E Carpenter), crawdad@fnal.gov (Matt Crawford), Big-Internet@munnari.OZ.AU In-Reply-To: <3.0.6.32.20001220143719.00a23c20@mailhost.ewd.3com.com> from "Cyndi Jung" at Dec 20, 2000 02:37:19 PM X-Mailer: ELM [version 2.5 PL1] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk One should remember that the RIRs are not in the business of routing packets for the prefixes they have been delegated. > > So why do all the non-6Bone routes begin with 2001? Doesn't that > identify the addressing authority (ARIN, RIPE, APNIC - I can't find > quickly the authority). It doesn't seem like there will be many > more addressing authorities at the top level - I don't expect a lot > of different values for those first 16 bits. But evidently you have > a different view of it. > > Cyndi > > At 03:43 PM 12/20/00 -0600, Brian E Carpenter wrote: > >Cyndi, > > > >TLAs are not supposed to be administrative. You are correct within the > >6BONE or the subTLAs of course, but the real future is genuine TLAs. Ideally > >we would see 2**13 subTLAs and 2**13 TLAs in the default-free table, and > >nothing else (after the 6BONE goes away). > > > >I realise we don't live in an ideal world, and that the pre-condition for > getting > >anywhere near the ideal is cracking the multihoming problem, i.e. find a > way to > >keep those /48s local. > > > > Brian > > > >Cyndi Jung wrote: > >> > >> Well, the first 16 bits are administrative, and the bits 49-64 > >> are "site specific", so *at worst* there are 32 bits to route on IF there > >> is nothing longer than a /48 in the BGP tables. My 6Bone node advertises > >> a /24, and really only 8 bits have any topological meaning, but of course > >> need the context of the first 16 bits. > >> > >> Cyndi > >> > >> At 09:04 AM 12/20/00 -0600, Brian E Carpenter wrote: > >> >And there was I hoping that we wouldn't see anything longer than /16 > >> >in the default-free zone. If we see /48s the way we are seeing > >> >IPv4 /24s today, we will be in deep trouble.We **really** need to > >> >fix the multihoming (for which there is now a separate list). > >> > > >> > Brian > >> > > >> >Cyndi Jung wrote: > >> >> > >> >> I think this is assuming the longest prefix that makes it into the > >> non-default > >> >> routing tables is a /48. > >> >> > >> >> Cyndi > >> >> > >> >> At 08:37 AM 12/19/00 -0600, Matt Crawford wrote: > >> >> >> full IPv4 host routes are identical to the space reserved for routing > >> IPv6 > >> >> >> addresses. The IPv6 space is "carved" up with the last 64 bits as > MAC > >> >> >> address and the first 32 as "address family", leaving the second > 32-bit > >> >> chunk > >> >> >> to define routing. > >> >> > > >> >> >Say what? > >> >> > > >> >> > > >> > > >> > > > > > > From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 10:43:38 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id XA29010; Thu, 21 Dec 2000 10:43:38 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: from localhost (localhost [[UNIX: localhost]]) by murtoa.cs.mu.OZ.AU id eBKNg2906056 for deliver-b-i-au; Thu, 21 Dec 2000 10:42:02 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKNfwX06053 for ; Thu, 21 Dec 2000 10:41:58 +1100 (EST) Received: from unknown (because of University of Melbourne policy) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id XA29093; Thu, 21 Dec 2000 10:28:47 +1100 (from brian@hursley.ibm.com) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA37970; Wed, 20 Dec 2000 15:19:49 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA27308; Wed, 20 Dec 2000 15:24:54 -0800 Message-Id: <3A413EF9.FABCE648@hursley.ibm.com> Date: Wed, 20 Dec 2000 17:21:29 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr Mime-Version: 1.0 To: Cyndi Jung Cc: Big-Internet@munnari.OZ.AU Subject: Re: 2x32 References: <3.0.6.32.20001219090943.02b2e2c0@mailhost.ewd.3com.com> <3.0.6.32.20001220120928.00ad8a60@mailhost.ewd.3com.com> <3.0.6.32.20001220143719.00a23c20@mailhost.ewd.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk 2001::/16 is the TLA that grandfathers the 2**13 subTLAs. Brian Cyndi Jung wrote: > > So why do all the non-6Bone routes begin with 2001? Doesn't that > identify the addressing authority (ARIN, RIPE, APNIC - I can't find > quickly the authority). It doesn't seem like there will be many > more addressing authorities at the top level - I don't expect a lot > of different values for those first 16 bits. But evidently you have > a different view of it. > > Cyndi > > At 03:43 PM 12/20/00 -0600, Brian E Carpenter wrote: > >Cyndi, > > > >TLAs are not supposed to be administrative. You are correct within the > >6BONE or the subTLAs of course, but the real future is genuine TLAs. Ideally > >we would see 2**13 subTLAs and 2**13 TLAs in the default-free table, and > >nothing else (after the 6BONE goes away). > > > >I realise we don't live in an ideal world, and that the pre-condition for > getting > >anywhere near the ideal is cracking the multihoming problem, i.e. find a > way to > >keep those /48s local. > > > > Brian > > > >Cyndi Jung wrote: > >> > >> Well, the first 16 bits are administrative, and the bits 49-64 > >> are "site specific", so *at worst* there are 32 bits to route on IF there > >> is nothing longer than a /48 in the BGP tables. My 6Bone node advertises > >> a /24, and really only 8 bits have any topological meaning, but of course > >> need the context of the first 16 bits. > >> > >> Cyndi > >> > >> At 09:04 AM 12/20/00 -0600, Brian E Carpenter wrote: > >> >And there was I hoping that we wouldn't see anything longer than /16 > >> >in the default-free zone. If we see /48s the way we are seeing > >> >IPv4 /24s today, we will be in deep trouble.We **really** need to > >> >fix the multihoming (for which there is now a separate list). > >> > > >> > Brian > >> > > >> >Cyndi Jung wrote: > >> >> > >> >> I think this is assuming the longest prefix that makes it into the > >> non-default > >> >> routing tables is a /48. > >> >> > >> >> Cyndi > >> >> > >> >> At 08:37 AM 12/19/00 -0600, Matt Crawford wrote: > >> >> >> full IPv4 host routes are identical to the space reserved for routing > >> IPv6 > >> >> >> addresses. The IPv6 space is "carved" up with the last 64 bits as > MAC > >> >> >> address and the first 32 as "address family", leaving the second > 32-bit > >> >> chunk > >> >> >> to define routing. > >> >> > > >> >> >Say what? > >> >> > > >> >> > > >> > > >> > > > > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 10:43:48 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id XA27936; Thu, 21 Dec 2000 10:43:48 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBKNgFs06061 for deliver-b-i-au; Thu, 21 Dec 2000 10:42:15 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBKNgCX06058 for ; Thu, 21 Dec 2000 10:42:12 +1100 (EST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id XA29779; Thu, 21 Dec 2000 10:39:40 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: bmanning@vacation.karoshi.com Cc: cmj@3Com.COM (Cyndi Jung), Big-Internet@munnari.OZ.AU Subject: Re: 2x32 In-Reply-To: Your message of "Wed, 20 Dec 2000 23:00:47 -0000." <200012202300.XAA26266@vacation.karoshi.com> Date: Thu, 21 Dec 2000 10:39:40 +1100 Message-Id: <13957.977355580@mundamutti.cs.mu.OZ.AU> Precedence: bulk Date: Wed, 20 Dec 2000 23:00:47 +0000 (UCT) From: bmanning@vacation.karoshi.com Message-ID: <200012202300.XAA26266@vacation.karoshi.com> | One should remember that the RIRs are not in the business of routing | packets for the prefixes they have been delegated. I'm not quite sure what the point of that comment was so perhaps this is way off target - but one should also remember that the RIRs are not assigned the addresses (TLAs) - they're just given stewardship over they're allocation to the transit net operators, whose business is exactly routing the packets. Then Bill included all of an earlier message from Cyndi Jung, which I will reply to here rather than separately (because I'm lazy) ... | > So why do all the non-6Bone routes begin with 2001? I suspect because only one TLA has actually been assighned and is in any kind of use yet - since none of the major backbone providers are actually routing IPv6, seeing even the one is perhaps extravagent. | > Doesn't that identify the addressing authority You can work out from the address (if there is a point in doing so) which registry assigned it - but the 2001 actually identifies the transit net to which the registry assigned the address. | > It doesn't seem like there will be many | > more addressing authorities at the top level No, probably not, but how many there are doesn't matter - we're not about to repeat the NSAP mistake of sticking registry identifier information in the top bits of the address. I'm not sure how many of the 8K TLAs have been assigned to the 3 registries that exist, but t doesn't really matter - there's not expected to be any relationship between 2002::/16 and 2003::/16 so one of those could be assigned by one registry, and another by another (or perhaps both by the same one). If one registry runs out of TLAs to assign, it can just get some more (if they're not all divided up already) or reclaim some unused ones from another registry. | > - I don't expect a lot | > of different values for those first 16 bits. But evidently you have | > a different view of it. I expect as many as there are large default free transit networks. At the present time, that might be a hundred or two (I'm guessing...) Over time it will grow most likely. kre From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 12:56:08 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id BA31225; Thu, 21 Dec 2000 12:56:08 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBL1sJg06168 for deliver-b-i-au; Thu, 21 Dec 2000 12:54:19 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBL1s8w06163 for ; Thu, 21 Dec 2000 12:54:08 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id BA30478; Thu, 21 Dec 2000 12:25:20 +1100 (from jhawk@bbnplanet.com) Received: from jhawk-foo.bbnplanet.com (jhawk-foo.bbnplanet.com [199.94.208.163]) by mumnunah.cs.mu.OZ.AU with ESMTP id MAA14358 for ; Thu, 21 Dec 2000 12:25:06 +1100 (EST) Received: (from jhawk@localhost) by jhawk-foo.bbnplanet.com (8.8.8+Sun/8.8.8) id UAA15015; Wed, 20 Dec 2000 20:18:10 -0500 (EST) Date: Wed, 20 Dec 2000 20:18:10 -0500 From: John Hawkinson To: Brian E Carpenter Cc: Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) Message-Id: <20001220201810.B14848@jhawk-foo.bbnplanet.com> References: <4.3.2.7.2.20001220045656.00b0de60@jumble.telstra.net> <4.3.2.7.2.20001221051555.00b163d0@jumble.telstra.net> <3A4128B9.223045F4@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.1i In-Reply-To: <3A4128B9.223045F4@hursley.ibm.com>; from brian@hursley.ibm.com on Wed, Dec 20, 2000 at 03:46:33PM -0600 Precedence: bulk > One way to find out why rational people did something is to ask them. > Would it be possible to select a random bunch of recent /24 > announcements, and ask the originating ISP "why did you do that?" > (with a suitable reason for asking and a promise of anonymity)? It's emminently reasonable, Brian. Are you volunteering to go and do it? [that's a serious question]. I think most operators reading along playing the big-internet home game suspect that the answers fall into two categories: a) people who are clueless b) people who have a topological requirement for that advertisement (i.e. multihoming). I guess, in saying that, I disagree with Geoff's theory (quoted below). From my perspective, it doesn't seem like a very interesting question, since the a) group will get fixed when we (operators) get annoyed enough at those people and "nuke them from orbit", and the b) group we have to live with until we have a superior system. --jhawk gih> But I'm NOT trying to explain what folk could do. The essential observation gih> is a rapid rise in the number of short prefixes in the routing table. The gih> next order question is WHY? Some folk are saying "Its just that many folk gih> who configure BGP sessions are dumb, ignorant, or both'. I'm saying "Thats gih> probably not right - lets see if there are a good reasons why this is gih> going on, and then see if we can find any supportive evidence in the gih> BGP tables to confirm that this is happening." From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 20:15:47 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA02987; Thu, 21 Dec 2000 20:15:47 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBL9EAt06440 for deliver-b-i-au; Thu, 21 Dec 2000 20:14:10 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBL9E4Y06435 for ; Thu, 21 Dec 2000 20:14:05 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id IA01552; Thu, 21 Dec 2000 19:51:57 +1100 (from bass@www.silkroad.com) Received: from www.silkroad.com (gate.silkroad.com [64.14.111.22]) by mumnunah.cs.mu.OZ.AU with ESMTP id TAA19362 for ; Thu, 21 Dec 2000 19:51:54 +1100 (EST) Received: from ibs (ibs.silkroad.com [64.14.111.24]) by www.silkroad.com (8.11.1/8.9.1) with SMTP id eBL8pHO03008 for ; Thu, 21 Dec 2000 03:51:17 -0500 Message-Id: <000d01c06b2a$3a09e7a0$186f0e40@silkroad.com> Reply-To: "Tim Bass" From: "Tim Bass" To: References: <4.3.2.7.2.20001221073416.00b08350@jumble.telstra.net> Subject: Re: AGGREGATE Date: Thu, 21 Dec 2000 03:44:26 -0500 Organization: Silk Road Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Precedence: bulk BGP is a dinosaur protocol completely rooted in the spanning-tree days of the NSFNET AUP and all subsequent hacks to BGP are based on this antiquated foundation. When one starts to speak of multi-homed routing in a confederation of AS; starting the discussion from a BGP perspective guarentees that a modern construct will not be reached. The minority of BGP proponents would do the net a great service to let go of BGP mentally and to build the high level operational constructs of a truely scaleable global routing protocol. It is really Zen to keep it simple and scaleable and to use the early constructs by Kleinrock and Kamoun to build an aggregation model that frees the net and does not bind it. The high level principles of scaleable global routing could be: (1) Global routing is completely decoupled from transit policy. (2) Global routing is based on flexible, robust databases mappings. (3) Global routing is non commerical nor political. (4) Global routing is not complex and follows the simplicity principle. (5) Global routing is supernet-centric and decoupled from manipulating IP addresses. (6) Global routing is aggregated based on scalelable, non commericial, non-political mappings betweens IP addresses (lowest level), AS (intermediate level) and Federations (higher level). (7) Global routing provides an equal entry point into service provisioning and eliminates all degree of commerical control or dominance based on commece, marketshare, and influence. These could be better written, of course; but the idea is to set guiding architectural principles before jumping into solution-engineering and getting wrapped around the axle of existing constraints. A big challenge is to get the gorilla vendors of the world to cooperate. The approach for that challenge must be unique because all other attempts have failed due to commerical interests. What comes to mind is legislative and regulatory, but this is suboptimal and will meet with a lot of push-back. However, the timing might be right to start this effort now that the big-internet commerical acceleration is slowing and will continue to reverse itself now that the dI/dt is slowing dramatically. From owner-Big-Internet@murtoa.cs.mu.OZ.AU Thu Dec 21 23:20:26 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id MA04006; Thu, 21 Dec 2000 23:20:26 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBLCIxC06543 for deliver-b-i-au; Thu, 21 Dec 2000 23:18:59 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBLCIqR06540 for ; Thu, 21 Dec 2000 23:18:52 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id KA07068; Thu, 21 Dec 2000 21:43:47 +1100 (from kurtis@kpnqwest.net) Received: from calvin.eunet.se (calvin.eunet.se [195.43.226.66]) by mumnunah.cs.mu.OZ.AU with ESMTP id VAA20103 for ; Thu, 21 Dec 2000 21:43:44 +1100 (EST) Received: from calvin.eunet.se (calvin.eunet.se [195.43.226.66]) by calvin.eunet.se (8.9.3/8.9.3) with ESMTP id LAA29213; Thu, 21 Dec 2000 11:39:45 +0100 (MET) Date: Thu, 21 Dec 2000 11:39:45 +0100 (MET) From: Kurt Erik Lindqvist X-Sender: kurtis@calvin.eunet.se Reply-To: Kurt Erik Lindqvist To: Geoff Huston Cc: Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) In-Reply-To: <4.3.2.7.2.20001221051555.00b163d0@jumble.telstra.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > If you have a better method of understanding why the BGP table is behaving > that way its is, I'd be pleased to hear it, as I've no particular desire > to delve into the practices of multi-homing multi-AS traffic engineering > on this list, other than to see if this is a contributory factor in the > BGP table's growth. No, I think you are right about the reason. I just think that there are better ways of doing the same. Best regards, - kurtis - Kurt Erik Lindqvist Kurtis.Lindqvist@KPNQwest.SE KPNQwest Sweden @ The speed of light http://www.kpnqwest.se PO Box 23163 S-10435 Stockholm From owner-Big-Internet@murtoa.cs.mu.OZ.AU Fri Dec 22 13:55:33 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id CA14359; Fri, 22 Dec 2000 13:55:33 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: from localhost (localhost [[UNIX: localhost]]) by murtoa.cs.mu.OZ.AU id eBM2rdM08208 for deliver-b-i-au; Fri, 22 Dec 2000 13:53:39 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBM2rVx08202 for ; Fri, 22 Dec 2000 13:53:31 +1100 (EST) Received: from unknown (because of University of Melbourne policy) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id XA18016; Fri, 22 Dec 2000 10:17:56 +1100 (from gih@telstra.net) Received: from tecra.telstra.net (gorp.telstra.net [203.50.0.66]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id KAA67134; Fri, 22 Dec 2000 10:15:25 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001222093612.00afe220@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Dec 2000 09:40:59 +1100 To: Robert Elz From: Geoff Huston Subject: Re: AGGREGATE Cc: "J. Noel Chiappa" , Big-Internet@munnari.OZ.AU In-Reply-To: <13296.977350120@mundamutti.cs.mu.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk What I find hard to figure out about kre's short term solution is that there is no economic or business forcing function to "come down hard on the core network" operators. There is no registry, no allocation vehicle and no authority models - there is only the motivation of the longer term common good to motivate what is essentially self-imposed restraint and self-imposed cost. I'm uncomfortable with such an approach as I don't think it has sufficient sway in deployed network, and I'm more inclined toward an approach of 'give us better tools so that we stop doing damage by using the wrong tool'. Geoff From owner-Big-Internet@murtoa.cs.mu.OZ.AU Fri Dec 22 13:55:33 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id CA14672; Fri, 22 Dec 2000 13:55:33 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBM2rjx08217 for deliver-b-i-au; Fri, 22 Dec 2000 13:53:45 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBM2rfx08212 for ; Fri, 22 Dec 2000 13:53:41 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id WA11029; Fri, 22 Dec 2000 09:00:18 +1100 (from brian@hursley.ibm.com) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by mumnunah.cs.mu.OZ.AU with ESMTP id JAA28105 for ; Fri, 22 Dec 2000 09:00:14 +1100 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA37892; Thu, 21 Dec 2000 13:52:12 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA27464; Thu, 21 Dec 2000 13:57:35 -0800 Message-Id: <3A427C6D.E0A9DA8@hursley.ibm.com> Date: Thu, 21 Dec 2000 15:55:57 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr Mime-Version: 1.0 To: John Hawkinson Cc: Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) References: <4.3.2.7.2.20001220045656.00b0de60@jumble.telstra.net> <4.3.2.7.2.20001221051555.00b163d0@jumble.telstra.net> <3A4128B9.223045F4@hursley.ibm.com> <20001220201810.B14848@jhawk-foo.bbnplanet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk I don't have ready access to BGP4 tables that would allow me to do this unaided. If somebody who does have such access is willing to work on it, I'd be very glad to colloborate as time permits. N.B. the question asked will *not* be "did you announce that /24 because you're a dork, or what?" Brian John Hawkinson wrote: > > > One way to find out why rational people did something is to ask them. > > Would it be possible to select a random bunch of recent /24 > > announcements, and ask the originating ISP "why did you do that?" > > (with a suitable reason for asking and a promise of anonymity)? > > It's emminently reasonable, Brian. Are you volunteering to go and do it? [that's > a serious question]. > > I think most operators reading along playing the big-internet home > game suspect that the answers fall into two categories: a) people who > are clueless b) people who have a topological requirement for that > advertisement (i.e. multihoming). I guess, in saying that, I disagree with > Geoff's theory (quoted below). > > >From my perspective, it doesn't seem like a very interesting question, > since the a) group will get fixed when we (operators) get annoyed > enough at those people and "nuke them from orbit", and the b) group > we have to live with until we have a superior system. > > --jhawk > > gih> But I'm NOT trying to explain what folk could do. The essential observation > gih> is a rapid rise in the number of short prefixes in the routing table. The > gih> next order question is WHY? Some folk are saying "Its just that many folk > gih> who configure BGP sessions are dumb, ignorant, or both'. I'm saying "Thats > gih> probably not right - lets see if there are a good reasons why this is > gih> going on, and then see if we can find any supportive evidence in the > gih> BGP tables to confirm that this is happening." From owner-Big-Internet@murtoa.cs.mu.OZ.AU Fri Dec 22 13:55:34 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id CA14293; Fri, 22 Dec 2000 13:55:34 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBM2rfC08210 for deliver-b-i-au; Fri, 22 Dec 2000 13:53:41 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBM2rax08205 for ; Fri, 22 Dec 2000 13:53:36 +1100 (EST) Received: from unknown (because of University of Melbourne policy) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id XA05223; Fri, 22 Dec 2000 10:18:14 +1100 (from gih@telstra.net) Received: from tecra.telstra.net (gorp.telstra.net [203.50.0.66]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id KAA67137; Fri, 22 Dec 2000 10:15:28 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001222094210.00af5950@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Dec 2000 09:44:26 +1100 To: John Hawkinson From: Geoff Huston Subject: Re: AGGREGATE (was: Re: Admin: Just flushing bad addresses from the list) Cc: Brian E Carpenter , Big-Internet@munnari.OZ.AU In-Reply-To: <20001220201810.B14848@jhawk-foo.bbnplanet.com> References: <3A4128B9.223045F4@hursley.ibm.com> <4.3.2.7.2.20001220045656.00b0de60@jumble.telstra.net> <4.3.2.7.2.20001221051555.00b163d0@jumble.telstra.net> <3A4128B9.223045F4@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk > >From my perspective, it doesn't seem like a very interesting question, >since the a) group will get fixed when we (operators) get annoyed >enough at those people and "nuke them from orbit", aka 'anti-competitive collusive trade practices'? I'm not sure that this will occur these days, whatever the merits of so doing. > and the b) group >we have to live with until we have a superior system. yep - and it would be good to understand the parameters of such a better system. From owner-Big-Internet@murtoa.cs.mu.OZ.AU Sat Dec 23 21:02:29 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id KA30398; Sat, 23 Dec 2000 21:02:29 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: from localhost (localhost [[UNIX: localhost]]) by murtoa.cs.mu.OZ.AU id eBNA0aR10344 for deliver-b-i-au; Sat, 23 Dec 2000 21:00:36 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBNA0To10341 for ; Sat, 23 Dec 2000 21:00:29 +1100 (EST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA30183; Sat, 23 Dec 2000 20:59:59 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Geoff Huston Cc: Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE In-Reply-To: Your message of "Fri, 22 Dec 2000 09:40:59 +1100." <4.3.2.7.2.20001222093612.00afe220@jumble.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Dec 2000 20:59:58 +1100 Message-Id: <3864.977565598@mundamutti.cs.mu.OZ.AU> Precedence: bulk Date: Fri, 22 Dec 2000 09:40:59 +1100 From: Geoff Huston Message-ID: <4.3.2.7.2.20001222093612.00afe220@jumble.telstra.net> | What I find hard to figure out about kre's short term solution | is that there is no economic or business forcing function | to "come down hard on the core network" operators. Hmm... I can read that in either of two ways, either you're saying that there's no problem, in which case we can all just go back to sleep. Or you're saying that there's no stick. If it is the latter, then I think you're wrong. For sure, there's nothing that anyone can do that will stop an operator from announcing the universe, if that is what they want to do. Doing that isn't hurting them any way at all - they need all their internal routes anyway. What it is doing however is to pollute the BGP tables of the rest of the network. The rest of the network can react, by simply refusing to take any notice of unnecessary routes. And "unnecessary" here doesn't mean identical, it means anything that doesn't actually break connectivity - whatever it does to the paths chosen. The argument against doing that (filtering incoming BPG) that I have heard (I think the only real one) is that the customers go elsewhere if you do that. Frankly to me, I doubt that the vast majority of customers know what a BGP route is, let alone what the effects of filtering them might be - as long as they get to communicate with everyone, they'll generally be happy enough. (Of course, there are a few clueful ones, most commonly I guess the slightly smaller (not default free) operators who want to be able to bend the routing tables to their own advantage). Note, here I'm not talking about a trivial filter (like filter out all prefixes longer than /18 or something) - more like filter all announcements which have an AS path that ends in the same AS as a shorter prefix that covers the longer one (and of course, no intermediate length prefix leading elsewhere). Perhaps even drop them if the immediate neighbour AS is the same (in the similar circumstances). But I'm no BGP or backbone routing expect to know exactly what the filtering ought to be. It is not self-restraint that we need, it is self-interest - everyone keeping the BGP tables that they process as small as possible. It may be necessary for the IETF (or IAB) to make a statement about the need to do this, to limit the BGP table growth, so the operators have something to show those people who will complain about the filtereing, just as was done with CIDR. It doesn't stop the complaints, but it does provide a fairly quick answer. And last - there's no collusive anti-competitive trade practices here at all - first, nothing is anti-competitive, each operator is just trying to make sure that they can (individually) compete best (if some can handle much larger tables than others, they could filter less). Second, there's no collusion - or no more than there is when all phone manufacturers use the same kind of plug on the end of the wire, and the same frequencies for dialing - sure that wildly hurts those other manufacturers who want to use something different, but simply following a standard is no anti-competitive, nor is making it, unless it was done for the purpose of keeping others out of the market. kre From owner-Big-Internet@murtoa.cs.mu.OZ.AU Sun Dec 24 00:22:10 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id NA32758; Sun, 24 Dec 2000 00:22:10 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBNDKgn10487 for deliver-b-i-au; Sun, 24 Dec 2000 00:20:42 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBNDKam10482 for ; Sun, 24 Dec 2000 00:20:37 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id MA31650; Sat, 23 Dec 2000 23:48:14 +1100 (from jhawk@bbnplanet.com) Received: from jhawk-foo.bbnplanet.com (jhawk-foo.bbnplanet.com [199.94.208.163]) by mumnunah.cs.mu.OZ.AU with ESMTP id XAA17836; Sat, 23 Dec 2000 23:48:06 +1100 (EST) Received: (from jhawk@localhost) by jhawk-foo.bbnplanet.com (8.8.8+Sun/8.8.8) id HAA18282; Sat, 23 Dec 2000 07:41:14 -0500 (EST) Date: Sat, 23 Dec 2000 07:41:14 -0500 From: John Hawkinson To: Robert Elz Cc: Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE Message-Id: <20001223074114.M14848@jhawk-foo.bbnplanet.com> References: <4.3.2.7.2.20001222093612.00afe220@jumble.telstra.net> <3864.977565598@mundamutti.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.1i In-Reply-To: <3864.977565598@mundamutti.cs.mu.OZ.AU>; from kre@munnari.OZ.AU on Sat, Dec 23, 2000 at 08:59:58PM +1100 Precedence: bulk On Sat, Dec 23, 2000 at 08:59:58PM +1100, Robert Elz wrote: > The argument against doing that (filtering incoming BPG) that I have > heard (I think the only real one) is that the customers go elsewhere if > you do that. Well, and also that the situation may not be sufficiently compelling (i.e. operators may have their hands full with other issues). > Note, here I'm not talking about a trivial filter (like filter out all > prefixes longer than /18 or something) - more like filter all announcements > which have an AS path that ends in the same AS as a shorter prefix that > covers the longer one (and of course, no intermediate length prefix leading > elsewhere). Perhaps even drop them if the immediate neighbour AS is > the same (in the similar circumstances). But I'm no BGP or backbone > routing expect to know exactly what the filtering ought to be. Well, some responses come to mind: a) BGP operators use relatively blunt instruments. There's a large prevelance of code from proprietary vendors where adding code to do the above requires lobbying the vendor. It's not as if one can trivially patch in such stuff on one's own and see how it performs. b) I could see this sort of thing having issues for convergency and consistent routing, if not done properly, and that might scare people. c) The idea that a third party might interfere with routing between two parties by injecting a shorter prefix coverring already extent routes between the two principals could be disturbing. We already have this potential issue with more-specifics, of course, but this could change the picture. > It is not self-restraint that we need, it is self-interest - everyone > keeping the BGP tables that they process as small as possible. Indeed, at the moment there is little incentive to do this, other than "being a good citizen," which, in today's larger operator community, isn't quite the carrot that it used to be. --jhawk From owner-Big-Internet@murtoa.cs.mu.OZ.AU Sun Dec 24 01:41:15 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id OA00803; Sun, 24 Dec 2000 01:41:15 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBNEdXo10552 for deliver-b-i-au; Sun, 24 Dec 2000 01:39:33 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBNEdS410547 for ; Sun, 24 Dec 2000 01:39:28 +1100 (EST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id OA00764; Sun, 24 Dec 2000 01:39:03 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: John Hawkinson Cc: Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE In-Reply-To: Your message of "Sat, 23 Dec 2000 07:41:14 CDT." <20001223074114.M14848@jhawk-foo.bbnplanet.com> Date: Sun, 24 Dec 2000 01:39:03 +1100 Message-Id: <5084.977582343@mundamutti.cs.mu.OZ.AU> Precedence: bulk Date: Sat, 23 Dec 2000 07:41:14 -0500 From: John Hawkinson Message-ID: <20001223074114.M14848@jhawk-foo.bbnplanet.com> | Well, and also that the situation may not be sufficiently | compelling (i.e. operators may have their hands full with | other issues). That's the "it isn't really a problem" response, and that's certainly possible ... that is, if the BGP table size (and the computations that it means) seem as if they're manageable now, and that the routers are increasing in capacity at a fast enough rate to keep up, then that's all fine. If that isn't all true, then I'd think the operators ought to be looking at finding a solution, especially if that is going to involve lobbying vendors for code changes. All the rest of what you say as reasons why this isn't being done today I understand completely - and if it doesn't need to be done to keep the BGP4 tables manageable, then I certainly don't want to see it done. The question is whether or not the global routing tables will eventually overrun the capacity to process them. If not, we're fine. If they will, then we need some kind of fix - and unless there's a better one out there somewhere which we're sure can be deployed in time, then applying administrative constraints on the size of the routing table sounds like it is what has to be done (like I said in the first message, in the short term anyway). | Indeed, at the moment there is little incentive to do this, other than | "being a good citizen," which, in today's larger operator community, | isn't quite the carrot that it used to be. Again, if you have no problem with your BGP routing table size, you should do nothing at all. If you do, then I would hae thought that it isn't just being a good citizen if you apply some kind of fix. kre From owner-Big-Internet@murtoa.cs.mu.OZ.AU Sun Dec 24 01:47:03 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id OA17079; Sun, 24 Dec 2000 01:47:03 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBNEjd910583 for deliver-b-i-au; Sun, 24 Dec 2000 01:45:39 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBNEjZ210580 for ; Sun, 24 Dec 2000 01:45:35 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id OA01160; Sun, 24 Dec 2000 01:43:18 +1100 (from randy@psg.com) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by mumnunah.cs.mu.OZ.AU with ESMTP id BAA18391 for ; Sun, 24 Dec 2000 01:43:16 +1100 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 149pqc-0007u4-00; Sat, 23 Dec 2000 06:40:34 -0800 From: Randy Bush Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: John Hawkinson Cc: Robert Elz , Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE References: <4.3.2.7.2.20001222093612.00afe220@jumble.telstra.net> <3864.977565598@mundamutti.cs.mu.OZ.AU> <20001223074114.M14848@jhawk-foo.bbnplanet.com> Message-Id: Date: Sat, 23 Dec 2000 06:40:34 -0800 Precedence: bulk > Well, and also that the situation may not be sufficiently > compelling (i.e. operators may have their hands full with > other issues). actually, when i prodded the biggest offender by one metric, i got back defensive rubbish about how the metric was broken. randy From owner-Big-Internet@murtoa.cs.mu.OZ.AU Sun Dec 24 10:58:54 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id XA03127; Sun, 24 Dec 2000 10:58:54 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBNNvH211945 for deliver-b-i-au; Sun, 24 Dec 2000 10:57:17 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBNNvE711942 for ; Sun, 24 Dec 2000 10:57:14 +1100 (EST) Received: from mumnunah.cs.mu.OZ.AU ([203.19.244.130]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id PA01271; Sun, 24 Dec 2000 02:45:22 +1100 (from jhawk@bbnplanet.com) Received: from jhawk-foo.bbnplanet.com (jhawk-foo.bbnplanet.com [199.94.208.163]) by mumnunah.cs.mu.OZ.AU with ESMTP id CAA18615; Sun, 24 Dec 2000 02:45:14 +1100 (EST) Received: (from jhawk@localhost) by jhawk-foo.bbnplanet.com (8.8.8+Sun/8.8.8) id KAA18714; Sat, 23 Dec 2000 10:38:26 -0500 (EST) Date: Sat, 23 Dec 2000 10:38:26 -0500 From: John Hawkinson To: Robert Elz Cc: Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE Message-Id: <20001223103826.N14848@jhawk-foo.bbnplanet.com> References: <20001223074114.M14848@jhawk-foo.bbnplanet.com> <5084.977582343@mundamutti.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.1i In-Reply-To: <5084.977582343@mundamutti.cs.mu.OZ.AU>; from kre@munnari.OZ.AU on Sun, Dec 24, 2000 at 01:39:03AM +1100 Precedence: bulk On Sun, Dec 24, 2000 at 01:39:03AM +1100, Robert Elz wrote: [ I said "may not be sufficiently compelling". ] > That's the "it isn't really a problem" response, and that's certainly > possible ... that is, if the BGP table size (and the computations that > it means) seem as if they're manageable now, and that the routers > are increasing in capacity at a fast enough rate to keep up, then > that's all fine. Err, no. It's more like it _seems_ manageable. There is a tendancy to operationalize and not be sufficiently forward-looking. The problems are not sufficiently binary soas to be easily detectable. For convergence issues, how bad is "too bad"? A second here or there may not be significant, but what if convergenfce degrades by seconds over years. Does anyone notice? More generally, do operators become inured to such degredations of service? Customers certainly do. Furthermore, operators will throw hardware at the problem. Throwing memory at the problem (of routing table size) is relatively easy, and perhaps that is a satisfactory solution. Certainly it's one where it appears that one has "solved" the problem (until it creeps back up), and the structure of growth is such that I think most operators feel that they have sufficient breathing room right now, once they've upgraded all their boxes since the last crisis. Router CPU is much fuzzier, so is pushing the BGP routing information bits around (bandwidth, etc.). It's hard to really assess those things in useful quantitative ways that imply clear metrics and resultant decisions. There are also tragedy-of-the-commons effects. If one hundred operators fixed one thing the world would be a better place, but if only one does, then it has little effect. How do you get folks to jump onto the bandwagon? And of course, there's the potential that we're being Chickens Little here. It's hard to say for sure until it is too late (that we may not have been sufficiently forward-loooking, or what-have-you). > All the rest of what you say as reasons why this isn't being done today > I understand completely - and if it doesn't need to be done to keep > the BGP4 tables manageable, then I certainly don't want to see it done. Assessing what needs to be done requires foreknowledge that is difficult to reliably obtain. --jhawk From owner-Big-Internet@murtoa.cs.mu.OZ.AU Sun Dec 24 11:03:48 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id AA04712; Sun, 24 Dec 2000 11:03:48 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBO02ON11976 for deliver-b-i-au; Sun, 24 Dec 2000 11:02:24 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBO02K711973 for ; Sun, 24 Dec 2000 11:02:20 +1100 (EST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id AA05811; Sun, 24 Dec 2000 11:02:20 +1100 (from Big-Internet-Request@munnari.OZ.AU) From: Robert Elz To: Big-Internet@munnari.OZ.AU Subject: Short gap in service... Date: Sun, 24 Dec 2000 11:02:19 +1100 Message-Id: <8874.977616139@mundamutti.cs.mu.OZ.AU> Precedence: bulk No more messages will get sent to the B-I list for the next 36 hours or so - sorry - I don't have adequate anti-spam auto filtering running yet to allow the list to auto-pilot. Messages will get queued till I am near a terminal again to check them and let the real ones through... kre From owner-Big-Internet@murtoa.cs.mu.OZ.AU Tue Dec 26 20:42:54 2000 Return-Path: Received: from murtoa.cs.mu.OZ.AU ([128.250.22.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA01055; Tue, 26 Dec 2000 20:42:54 +1100 (from owner-Big-Internet@murtoa.cs.mu.OZ.AU) Received: by murtoa.cs.mu.OZ.AU id eBQ9ei915664 for deliver-b-i-au; Tue, 26 Dec 2000 20:40:44 +1100 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.22.2]) by murtoa.cs.mu.OZ.AU with SMTP id eBQ9efL15661 for ; Tue, 26 Dec 2000 20:40:42 +1100 (EST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA00891; Tue, 26 Dec 2000 20:40:05 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: John Hawkinson Cc: Big-Internet@munnari.OZ.AU Subject: Re: AGGREGATE In-Reply-To: Your message of "Sat, 23 Dec 2000 10:38:26 CDT." <20001223103826.N14848@jhawk-foo.bbnplanet.com> Date: Tue, 26 Dec 2000 20:40:04 +1100 Message-Id: <25422.977823604@mundamutti.cs.mu.OZ.AU> Precedence: bulk Date: Sat, 23 Dec 2000 10:38:26 -0500 From: John Hawkinson Message-ID: <20001223103826.N14848@jhawk-foo.bbnplanet.com> | Err, no. It's more like it _seems_ manageable. There is a tendancy to | operationalize and not be sufficiently forward-looking. But that's what we're supposed to be doing here isn't it - just as was done back in the early 90's when address space started running out, and which eventually led to CIDR, and address rationing, and ... | The problems | are not sufficiently binary soas to be easily detectable. Life doesn't have to be easy. | Furthermore, operators will throw hardware at the problem. If that works, that's just fine - except that that is what was suggested before, and then the operators claimed that that wouldn't even be a solution, the hardware couldn't grow fast enough, and limiting address space growth, and making it aggregable were necessary. If it turns out that more hardware is a workable answer (this time), that's great. | There are also tragedy-of-the-commons effects. If one hundred operators | fixed one thing the world would be a better place, but if only one | does, then it has little effect. How do you get folks to jump onto | the bandwagon? Again you're concentrating upon others doing things for the benefit of others (which is, I auppose, the correct analog of CIDR). I was suggesting that operators do things for their own benefit, and forget everyone else (selfishness to the end). If everyone manages to do that successfully, then the net survives... If some fail, then they vanish eventually (either completely, or down the tree to become a smaller player). If no-one succeeds (or not enough do), then we have problems. It seems like here that what is necessary right now is to collect and analyse the data, determine if there is a problem (or whether we are just imagining a potential problem which isn't actually materialising) and then if there is, see if there is a good solution that can be deployed within the time limits (since we're talking about gradual growth outgrowing capacity here - there is time to work) and if no good solution can be found that can be deployed soon enough, then we look for some kind of hack we can tell people is the way to survive (and document it as the agreed way to survive). | And of course, there's the potential that we're being Chickens Little | here. It's hard to say for sure until it is too late (that we may not | have been sufficiently forward-loooking, or what-have-you). Yes. But this is no different than 8-9 years ago when all this started the last time. | Assessing what needs to be done requires foreknowledge that is difficult | to reliably obtain. Guesswork... (well, OK, inspired guesswork...) kre