- NANOG - lists.nanog.org

(no subject)
by srihari varada 08 Jun '01

08 Jun '01

Hello: I would like to request for input on the startup/boot times experienced by service providers, from commercial network equipment, and the ranges desired. To narrow down the scope, the following is provided: -- the best possible times observed from equipments of a mix of vendors -- the equipments perform routing function at the POP of a service provider in the access domain. -- two cases (the high end and low end) can be assumed to have a feel for the port density and the network interface types. Regards, Srihari Varada

1 0

RE: /24s run amuck again
by Karyn Ulriksen 08 Jun '01

08 Jun '01

I had a full /19 sliced and diced up into /24 until yesterday when I officially completed my data center migration. None appear in the list below. How recent is this information? Karyn :: -----Original Message----- :: From: Richard A. Steenbergen [mailto:ras@e-gerbil.net] :: Sent: Friday, June 08, 2001 12:51 AM :: To: nanog(a)merit.edu :: Subject: /24s run amuck again :: :: :: :: We all know that /24s have run amuck. According to the APNIC bgp :: statistics (http://www.apnic.net/stats/bgp) view of the internet, the :: current prefix distribution looks: :: :: Routing Table Report June 08, 2001 :: BGP routing table entries examined: 106727 :: :: Number of prefixes announced per prefix length (Global) :: ------------------------------------------------------- :: :: /1:0 /2:0 /3:0 /4:0 /5:0 :: /6:0 :: /7:0 /8:20 /9:5 /10:6 /11:9 :: /12:32 :: /13:77 /14:207 /15:346 /16:6905 /17:1175 :: /18:2174 :: /19:6720 /20:5247 /21:4509 /22:6779 /23:8684 :: /24:61402 :: /25:278 /26:450 /27:463 /28:489 /29:374 :: /30:317 :: /31:1 /32:58 :: :: This mean over 57% of the routing table consists of /24s. So :: in order to :: facilitate getting this fixed, I have prepared a list of the worst :: offenders and their specific blocks which (most likely) have :: no reason for :: not being aggregated. If all of these entries could be :: aggregated (and I'm :: certain this simple script missed some), it would reduce the :: routing table :: by over 29,000 entries, to less the 78k. I think it's pretty :: obvious that :: a lot of these simply have no excuse. :: :: :: http://www.e-gerbil.net/ras/projects/ipaddr/24amuck.txt :: :: :: A list of ASNs with the largest sized offending blocks (not :: overall count, :: #1 is UU #2 is BBN #3 is Telstra nothing unexpected there) is: :: :: 2711 - Rock Hill Telephone Company :: 8112 - Bell Atlantic Internet Solutions :: 701 - UUNet Technologies, Inc. :: 11371 - Rhythms NetConnections :: 226 - Los Nettos :: 7029 - Alltel Information Services, Inc. :: 18687 - MGC Communications, Inc. :: 6595 - DoD Education Activity Network Assistance Center :: 1677 - ANS Communications :: 1785 - AppliedTheory Corporation :: 1326 - Advanced Networks & Services Inc. :: 6499 - Brooks Fiber Properties, Inc. :: :: I highly encourage anyone interested to yell at these people. :: :: -- :: Richard A Steenbergen <ras(a)e-gerbil.net> :: http://www.e-gerbil.net/ras :: PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 :: D8 14 36 FE B6) :: :: :: ::

1 0

RE: Tiers and other sales speak
by Barrows, Jeff 08 Jun '01

08 Jun '01

Jason Lewis [mailto:jlewis@jasonlewis.net] wrote: > > Someone from MAE-Dulles called me and said they were a 2nd > generation MAE. What in the world is that? > > TAG changed their name to MAE-Dulles. My guess is to try to > make people think they were somehow related to MAE-East. > > No mention of tier at all....it's a new "generation". > > jas These guys seem to be trying to leverage the MAE "brand" for their own benefit, while trying to trash the existing MAEs at the same time for their own good. They sell transit. They buy from the people that they show as being present at their "MAE." I suspect that you can indeed inter-connect with other entities at their facilities-- through their /layer three routers./ This page has to be the most humorous: http://www.maedulles.net/topology.htm ...with this bit about their constraint-based BGP-4 being my favorite: "Advanced Border Gateway Protocol (BGP-4) directs traffic from its point of origin to the core class router of the least congested backbone, bypassing the congested public peering points and virtually eliminating latency and packet loss. " I can't wait for the "White Papers" link to become active. I'm guessing they didn't get permission to use the MAE acronym, [which presumably is trademarked] or the likeness of Dulles Airport in their logo. When they spoke of the "new generation," did they mention generation d? - jsb -- Jeff Barrows SVP, Global Networks Aleron Internet http://www.aleron.com +1 703 287 4224 Office

2 1

Tiers and other sales speak
by Jason Lewis 08 Jun '01

08 Jun '01

Someone from MAE-Dulles called me and said they were a 2nd generation MAE. What in the world is that? TAG changed their name to MAE-Dulles. My guess is to try to make people think they were somehow related to MAE-East. No mention of tier at all....it's a new "generation". jas

2 1

APNIC allocation policy documentation
by ggm＠apnic.net 08 Jun '01

08 Jun '01

FYI here are the references which we think document our allocation and assignment policies. At the Scottsdale NANOG-22, Steve Bellovin (?and Randy?) complained of a lack of APNIC documentation on allocation policy. The URLS below may not have been easily findable at the time. We have tried to ensure they are now indexed from the base page. When we do a reorganization on the site, I will try to ensure these are well linked. cheers -george ---- IPv4 allocation and assignment policies: http://www.apnic.net/docs/add-manage-policy.html (this one is linked from the http://www.apnic.net/policies.html URL which is itself linked from the main page under "Document Library") Minimum allocation per /8: http://www.apnic.net/db/min-alloc.html (this is linked from the http://www.apnic.net/general.html#stats URL which is on the main page) cheers -George -- RIPE comparison of allocation policy http://www.ripe.net/ripencc/mem-services/registration/rir-comp-matrix-rev.h…

1 0

/24s run amuck again
by Richard A. Steenbergen 08 Jun '01

08 Jun '01

We all know that /24s have run amuck. According to the APNIC bgp statistics (http://www.apnic.net/stats/bgp) view of the internet, the current prefix distribution looks: Routing Table Report June 08, 2001 BGP routing table entries examined: 106727 Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:5 /10:6 /11:9 /12:32 /13:77 /14:207 /15:346 /16:6905 /17:1175 /18:2174 /19:6720 /20:5247 /21:4509 /22:6779 /23:8684 /24:61402 /25:278 /26:450 /27:463 /28:489 /29:374 /30:317 /31:1 /32:58 This mean over 57% of the routing table consists of /24s. So in order to facilitate getting this fixed, I have prepared a list of the worst offenders and their specific blocks which (most likely) have no reason for not being aggregated. If all of these entries could be aggregated (and I'm certain this simple script missed some), it would reduce the routing table by over 29,000 entries, to less the 78k. I think it's pretty obvious that a lot of these simply have no excuse. http://www.e-gerbil.net/ras/projects/ipaddr/24amuck.txt A list of ASNs with the largest sized offending blocks (not overall count, #1 is UU #2 is BBN #3 is Telstra nothing unexpected there) is: 2711 - Rock Hill Telephone Company 8112 - Bell Atlantic Internet Solutions 701 - UUNet Technologies, Inc. 11371 - Rhythms NetConnections 226 - Los Nettos 7029 - Alltel Information Services, Inc. 18687 - MGC Communications, Inc. 6595 - DoD Education Activity Network Assistance Center 1677 - ANS Communications 1785 - AppliedTheory Corporation 1326 - Advanced Networks & Services Inc. 6499 - Brooks Fiber Properties, Inc. I highly encourage anyone interested to yell at these people. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

3 2

Bell Labs' Discovery May Lead to Efficient Networks
by Irwin Lazar 08 Jun '01

08 Jun '01

FYI: Bell Labs recently conducted an analysis of the nature of Internet traffic. Some pretty interesting findings. http://Networking.ittoolbox.com/browse.asp?c=NetworkingNews&r=/news/dispnews .asp?i=44100 Through the use of sophisticated new software programs that analyzed and simulated data traffic in "unprecedented detail," Bell Labs researchers found that the "burstiness" seen in traffic at the edges of the Internet disappears at the core. The discovery that traffic on heavily loaded, high-capacity network links is unexpectedly regular may point the way to more efficient system and network designs with better performance at lower cost, Bell Labs said.

6 6

backup relationships possibly harmful
by Randy Bush 08 Jun '01

08 Jun '01

in the paper by gao, griffin, and rexford, it is shown that backup transit low-pref relationships as done today can lead to routing loops. it's worth a look just for that. while the authors propose a protocol approach, i wonder if there is an operational approach. randy --- From: Jennifer Rexford <jrex(a)research.att.com> To: randy(a)research.att.com Cc: griffin(a)research.att.com Subject: backup relationships Date: Wed, 6 Jun 2001 15:24:31 -0400 (EDT) Randy, Following up on our conversation this afternoon about backup routes and convergence problems, see Lixin Gao, Tim Griffin, and Jennifer Rexford, "Inherently safe backup routing with BGP," Proc. IEEE INFOCOM, April 2001. http://www.research.att.com/~jrex/papers/infocom01.ps and the slides at http://www.research.att.com/~jrex/talks/infocom01.ps http://www.research.att.com/~jrex/talks/infocom01.ppt The slides give a relatively theory-free overview. The intro of the paper presents the problem and the key results of the paper, and the body of the paper has some examples worked out and a fair amount of Greek to prove that our proposals handle the problem. The paper builds on earlier work by Tim on the stable paths problem (INFOCOM'00) and the non-convergence of some BGP configurations (SIGCOMM'99), and by Lixin and me on showing how policies based on peer-peer and customer-provider relationships can prevent these problems (SIGMETRICS'00). Backup routes throw a wrench into the work that Lixin and I did; this INFOCOM'01 paper proposes a way to deal with that problem. See the section on "global sanity of BGP routing" at http://www.research.att.com/~griffin/interdomain.html#divergepapers for the papers. -- Jen

2 1

Re: Why so little traffic from C&W
by George William Herbert 08 Jun '01

08 Jun '01

JD wrote: >Mikael Abrahamsson <swmike(a)swm.pp.se> wrote: >> I believe the whole structure of tier1, tier2 etc is breaking down and >> everybody is going after all customers, and that this will have >> interesting implications in the future. > > Breaking down? It used to be that anyone connected directly > to an exchange point was tier one, and the tiers are pretty > obvious beyond that. Now that everyone's at the exchanges, > "tier one" is simply a marketing term. To "an" exchange point? It certainly didn't start out that way; in the 93-94 timeframe it was pretty clear tier 1's brought their bandwidth around the country and connected wherever possible, not just at one point. I have to agree that the "structure" is breaking down, if nothing else because people don't agree with what the definitions are (though, a coherent case can be made that we never did... like peering policies spinning in the wind, definitions have changed a lot over the years). -george william herbert gherbert(a)retro.com

1 0

New mailing list: model-peer
by Sean Donelan 08 Jun '01

08 Jun '01

I tried sending this earlier, but I think the list server caught it as a command. So here goes again. I have set up a new mailing list for discussing topics releated to peering, and what should go into a model peering agreement between providers. This is partially related to the BOF Stephan Stuart held at the last NANOG and recent discussions on the NANOG mailing list. > Post message: model-peer(a)yahoogroups.com > Subscribe: model-peer-subscribe(a)yahoogroups.com > Unsubscribe: model-peer-unsubscribe(a)yahoogroups.com > List owner: model-peer-owner(a)yahoogroups.com

1 0