- NANOG - lists.nanog.org

Re: IGP Comparison (Summary of Responses)
by Ehab Hadi 09 Jan '99

09 Jan '99

And not only that. Each ISP has it's own applications, requirement, and traffic patterns. Deploying various IGP might add values. --Ehab >Date: Fri, 08 Jan 1999 14:06:51 -0500 >To: Antoni Przygienda <prz(a)dnrc.bell-labs.com> >From: Scott Brim <swb(a)newbridge.com> >Subject: Re: IGP Comparison (Summary of Responses) >Cc: nanog(a)merit.edu > >At 12:46 PM 1/8/99 -0500, Antoni Przygienda wrote: >ISPs are customers here and until the world converges >>on one >>protocol (if it ever will), their needs should be met. > >If we do see pressure for convergence, it will be evidence that we've >lost our hold on the multi-tier model. If we like the multi-tier model >(and so far it's been useful) then we want to continue to make the IGP >you run in a given domain a local matter. If it weren't we never would >have seen OSPF or ISIS deployed widely in the first place. > > >Cordiali saluti ... Scott > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Test-Disregard This
by Martin, Christian 09 Jan '99

09 Jan '99

Test

1 0

agenda topics so far
by Susan R. Harris 08 Jan '99

08 Jan '99

Greetings - here are agenda topics we've come up with so far for the Denver NANOG meeting (Jan. 31 - Feb. 2). Let us know what else you'd like to hear about by sending e-mail to nanog-support(a)nanog.org, and watch for further details at: http://www.nanog.org/mtg-9901 Hope you can join us! ---------- - MPLS: Progress in the IETF from an ISP Perspective (Curtis Villamizar, ANS; other speakers TBA) - Deploying Inter-Domain Multicast Routing (Dino Farinacci, Cisco) - Academic NGI Networking: What's the Difference Between Internet2, Abilene, and the vBNS? (Paul Love, Internet2; Guy Almes, Advanced Network & Services; John Jamison, MCI; other speakers TBA) - ARIN Update (Kim Hubbard, ARIN) - Cflowd Update (includes BOF covering configuration details) (Daniel McRobb, Cooperative Association for Internet Data Analysis) (CAIDA) - IRcache Web Proxy Bake-Off (Duane Wessels, University of California, San Diego) - Internet Engineering Curriculum (Evie Nemeth, CAIDA) ------------------- BOFs - Switch Migration and Renumbering at the Chicago NAP (Andrew Schmidt, AADS) - Managing Filters and Traffic Shaping in Complex Networks (Pete Kruckenberg, inQuo) ------------------------------------------------------------------------- Susan R. Harris, Ph.D. Merit Network, Inc. Phone: 734.936.2100 srh(a)merit.edu Senior Science Writer Fax: 734.647.3185 -------------------------------------------------------------------------

1 0

The Cidr Report
by Tony Bates 08 Jan '99

08 Jan '99

This is an auto-generated mail on Fri Jan 8 12:00:00 PST 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 08Jan99 0) General Status Table History ------------- Date Prefixes 010199 55011 020199 55001 030199 54615 040199 54770 050199 54954 060199 54958 070199 55003 080199 54976 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 4389 Number of ASes announcing only one prefix: 2167 (1158 cidr, 1009 classful) Largest number of cidr routes: 351 announced by AS3561 Largest number of classful routes: 1010 announced by AS701 1) Gains by aggregating at the origin AS level --- 08Jan99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 391 145 246 62.9% UNKNOWN AS3749 231 71 160 69.3% UNKNOWN AS701 1010 861 149 14.8% UNKNOWN AS2493 326 179 147 45.1% UNKNOWN AS174 669 546 123 18.4% UNKNOWN AS5668 131 35 96 73.3% UNKNOWN AS4200 188 97 91 48.4% UNKNOWN AS4755 150 68 82 54.7% UNKNOWN AS1267 111 30 81 73.0% UNKNOWN AS4293 207 135 72 34.8% UNKNOWN AS549 220 154 66 30.0% UNKNOWN AS4740 393 329 64 16.3% UNKNOWN AS8517 133 74 59 44.4% UNKNOWN AS1221 381 323 58 15.2% UNKNOWN AS7046 251 195 56 22.3% UNKNOWN AS72 89 37 52 58.4% UNKNOWN AS7657 140 89 51 36.4% UNKNOWN AS3493 248 197 51 20.6% UNKNOWN AS7545 114 64 50 43.9% UNKNOWN AS1239 530 483 47 8.9% UNKNOWN AS10928 95 48 47 49.5% UNKNOWN AS7496 74 28 46 62.2% UNKNOWN AS577 205 160 45 22.0% UNKNOWN AS852 175 133 42 24.0% UNKNOWN AS719 452 410 42 9.3% UNKNOWN AS3221 84 42 42 50.0% UNKNOWN AS803 71 35 36 50.7% UNKNOWN AS7122 109 75 34 31.2% UNKNOWN AS1 503 470 33 6.6% UNKNOWN AS6897 46 14 32 69.6% UNKNOWN For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

IGP Comparison (Summary of Responses)
by Dan Rabb 08 Jan '99

08 Jan '99

In the process of selecting an IGP to run on a large scale nationwide IP Network, I received many responses to my NANOG request for information on IS-IS versus OSPF protocols. Most of the resources mentioned in the responses, however, were bias towards OSPF. There was not much information on IS-IS to be found, although obviously some individuals are satisfied enough with this protocol that is it still in place in large networks. Thank you to everyone who responded to my request. Rather than responding to each of you individually, I have summarized the information I received below (although admittedly one-sided). General: "The two are really pretty much equivalent, other than that IS-IS is intended for OSI networks while OSPF is for IP networks. Then there's "Integrated IS-IS" that handles both." Politics: "In fact, a number of members in the OSPF working group feared that IS-IS would be preferred for "political" reasons, as part of a grand plan to convert the Internet to OSI correctness, even if that meant a complete disruption of the service."(1) "There were also non-technical considerations. Many people felt that it was better that the IETF have complete control over the OSPF protocol design rather than depend on an ISO committee whose goals, namely to produce a routing protocol for the OSI protocol stack, were somewhat different."(2) Technical Issues: The following are excerpt from John Moy's book discusses the reasons that the IETF went ahead with the development of OSPF even though IS-IS was already being developed: "First, IS-IS ran directly over the link layer, which we thought was the wrong choice for a TCP/IP routing protocol..." "IS-IS had an area routing scheme, but one that did not allow any shortcuts between areas that we thought were necessary for an Internet routing protocol." "Also, IS-IS made no attempt to align fields in their packet formats, making life more difficult for protocol implementers." "It is possible to run IS-IS on an IP-only network, but, even if one does not want to forward CLNP datagarms, one will have to install in the routers the low-level code that demultiplexes CLNP and IS-IS packets. The "area" model of IS-IS is designed for CLNP where the rigidity and connectivity requirements are somewhat compensated by the possibility to perform automatic address assignment; when one uses IS-IS for IP, the rigidity remains, but the advantages disappear. IS-IS suffers from at least two other problems; a tiny metric and a limit to what a router can advertise. Having only 6 bits to express a link's metric is not really a good idea. It may make some messages shorter, but it certainly diminishes the routing's precision. Then, using the 8-bit link state record number to identify the link state record's will limit to 256 the number of records that a given router can advertise. As the size of each record is limited to the maximum packet size supported by the network, this can prove to be a severe constraint."(1) Dr. Huitema goes on to state some advantages of OSPF over IS-IS: * Support of a backup designated router * Coexistence with RIP through "not-so-stubby-areas" [Okay, this ones a little dated] * OSPF is "change controlled" by the IETF, evolution of OSI Protocols was much slower and that it responded to many other forces besides user needs. Ron Johnson wrote: OSPF: Uses a multicast address and standard IP transport to carry it's packets. IS-IS: Uses it own transport method to carry it's packets. OSPF: Scales well when the Backbone/area/stub model is correctly implemented, otherwise with many routers in a single area, it can have a definite performance impact on routing convergence times. IS-IS: Is less sensitive to growth problems then OSPF. OSPF: Is easier to implement and understand. It is more widely used, and supported amongst many vendors. IS-IS: Is more arcane. Harder to implement and understand it's operation and behavior, and may not be supported on every router. So, the bottom line, for me is; Use OSPF V2, if you are building a network where you can create a "backbone" area and then other logical areas attached to the backbone. Then aggregate and summarize your route announcements in your areas and announce the summarized routes into the backbone area. You will end up with less routes in your IGP. Which in turn means lower OSPF recalculation times, better performance and a more stable IGP. References: (1)"Routing and the Internet" By: Christian Huitema (ISBN: 0131321927) (2)"OSPF Anatomy of an Internet Routing Protocol" By: John Moy (ISBN: 0201634724) "Routing TCP/IP Volume I" By: Jeff Doyle, CCIE (ISBN:1578700418) RFC2178 "OSPF Version 2" (http://www.faqs.org/rfcs/rfc2178.html) RFC1195 "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments" (http://www.faqs.org/rfcs/rfc1195.html) RFC1371 "Choosing a "Common IGP" for the IP Internet (The IESG's Recommendation to the IAB)" (http://www.faqs.org/rfcs/rfc1370.html) Previous NANOG Discussions on this topic: http://www.cctec.com/maillists/nanog/historical/9810/threads.html#00484 Other References I have yet to review: "Interconnections: Bridges and Routers" By: Radia Perlman (ISBN: 0201563320) "The Great IGP Debate--Part One:IS-IS and Integrated Routing." By: R. Perlman and R. Callon (ConneXions 5, no. 10, October 1991) "The Great IGP Debate--Part Two:The Open Shortest Path First (OSPF) Routing Protocol." (ConneXions 5, no. 10, October 1991) Dan Rabb Network digital broadcast network dan(a)dbn.net

5 4

Re: waiting... waiting... waiting... on hold... with NSI (fwd)
by Patrick Greenwell 08 Jan '99

08 Jan '99

Thought this might be of interest... /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell (800) 299-1288 v CTO (925) 377-1212 v NameSecure (925) 377-1414 f Coming to the ISPF-II? The Forum for ISPs by ISPs http://www.ispf.com \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ ---------- Forwarded message ---------- Date: Fri, 8 Jan 1999 07:46:40 -0500 From: Chuck Gomes <cgomes(a)INTERNIC.NET> Reply-To: cgomes(a)netsol.com To: DOMAIN-POLICY(a)LISTS.INTERNIC.NET Subject: Re: waiting... waiting... waiting... on hold... with NSI We are experiencing major attacks by speculators spamming us with requests for domain names. Please bear with us as we work to filter them out and restore service to normal. Chuck -----Original Message----- From: philippe landau [mailto:lists@A-Z-INTERNET.COM] Sent: Friday, January 08, 1999 1:17 AM To: DOMAIN-POLICY(a)LISTS.INTERNIC.NET Subject: Re: waiting... waiting... waiting... on hold... with NSI >Same here: Submitted two almost identical domain name registration templates >two days ago (exact same time). Received tracking numbers several hours >later. One registration was completed yesterday. The other ticket's status >still reads "Ticket 'NIC-990106.xxxxx' not found!". > >To me this smells like major (database) trouble over there at the InterNIC - >especially when compared to the 20 minutes domain name registration >turnaround we had in past months ... That is absolutely correct and there is no doubt about it. Some domains are registered within 20 minutes (with a ticket often arriving one day later). other domains (requested within the same hour) are registered one week later. For other requests no ticket nor anything after two weeks. Questions to hostmaster(a)internic.net are usually not answered. No difference if you use a premier partner channel or not. and if you get an answer from somebody at internic regarding the reason of the problems: lies all over the place (i don't invent this). Usually you are lucky and everything goes fast. But in many cases it is a despair. I know computers and databases have and make problems, much more then usually admitted. But openness is the condition for improvement. Please, Internic, come out and tell us: if everybody knows you are working to solve the problems it will be obvious that you need the money you get. chin up, Philippe, A-Z-Internet.com -- DOMAIN-POLICY administrivia should be sent to <listserv(a)lists.internic.net> To unsubscribe send a message with only one line "SIGNOFF DOMAIN-POLICY" For more help regarding Listserv commands send the one line "HELP" -- DOMAIN-POLICY administrivia should be sent to <listserv(a)lists.internic.net> To unsubscribe send a message with only one line "SIGNOFF DOMAIN-POLICY" For more help regarding Listserv commands send the one line "HELP"

1 0

OUTAGE: fiber between Phoenix and LA
by Sean Donelan 07 Jan '99

07 Jan '99

Presently MCI/Worldcom have counted 96 DS3's, 15 OC12's, and 5 Tran48's (??) involved in the outage, so speaking with a tech right now is a little difficult... -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

OUTAGE: Fiber cut between Phoenix and LA
by Sean Donelan 07 Jan '99

07 Jan '99

The weather must have warmed up, there is a large fiber cut between Phoenix and Los Angeles. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: your mail
by steve＠altrina.exodus.net 07 Jan '99

07 Jan '99

yes.. seriously.. any way that nanog can maybe check the host that the people are pretending to be? :) I mean, now i'm gonna get a billion messages as to why I did this, and I didn't even do it :) On Thu, Jan 07, 1999 at 12:51:51PM -0800, Andrew Daniels wrote: > could we get any more of a lame spoof? I mean please.. > > -A > > On Thu, 7 Jan 1999 steve(a)altrina.exodus.net wrote: > > ]Received: from laguna.taos.com (laguna.taos.com [204.188.112.62]) > ] by quad.quadrunner.com (8.8.7/8.8-QUAD(1)) with ESMTP id MAA03561 > ] for <adaniels(a)quad.quadrunner.com>; Thu, 7 Jan 1999 12:46:08 -0800 > ]Received: from merit.edu (merit.edu [198.108.1.42]) > ] by laguna.taos.com (8.8.5/8.8.4) with ESMTP > ] id MAA09943 for <adaniels(a)taos.com>; Thu, 7 Jan 1999 12:44:45 -0800 (PST) > ]Received: from localhost (daemon@localhost) > ] by merit.edu (8.9.1a/8.9.1) with SMTP id PAA25737; > ] Thu, 7 Jan 1999 15:41:52 -0500 (EST) > ]Received: by merit.edu (bulk_mailer v1.5); Thu, 7 Jan 1999 15:33:08 -0500 > ]Received: (from majordom@localhost) > ] by merit.edu (8.9.1a/8.9.1) id PAA25503 > ] for nanog-outgoing; Thu, 7 Jan 1999 15:32:36 -0500 (EST) > ]Received: from ns.suspend.net (root(a)suspend.net [204.17.38.97]) > ] by merit.edu (8.9.1a/8.9.1) with ESMTP id PAA25499 > ] for <nanog(a)merit.edu>; Thu, 7 Jan 1999 15:32:31 -0500 (EST) > ]From: steve(a)altrina.exodus.net > ---- > ]Received: from rr.com (ci654377-a.grnvle1.sc.home.com [24.4.236.32]) by > ns.suspend.net (8.8.7/8.6.9) with SMTP id PAA17334 for nanog(a)merit.edu; Thu, > 7 Jan 1999 15:31:12 -0500 -- Steven O. Noble -- Sr. Backbone Engineer, Exodus Communications (EXDS) All my love to the Canadian Mooing Frog.

1 0

None
by steve＠altrina.exodus.net 07 Jan '99

07 Jan '99

ShdwKnght Jason Diekman 26876 Calle Alcala Mission Viejo CA 92691 949-458-5748 949-548-9441

1 0