- NANOG - lists.nanog.org

RE: OSPF -vs- ISIS
by Mike Bernico 21 Jun '05

21 Jun '05

The State of Illinois converted to ISIS in 2002 from EIGRP and it has definitely been a good thing for us. It's been operationally bullet proof, and simple to maintain. We typically get features faster than we would if we ran OSPF. For example, we have a desire in the future to use IPFRR. Every indication from the vendor is that this feature will be available to ISIS first, most likely because of either the extensibility of ISIS or more likely because ISIS is in so many larger providers. Mike Bernico -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of vijay gill Sent: Tuesday, June 21, 2005 9:20 AM To: Dan Evans Cc: nanog(a)merit.edu Subject: Re: OSPF -vs- ISIS Dan Evans wrote: > All, > > Can anyone point me to information on what the top N service providers > are using for their IGP? I'm trying to build a case for switching from > OSPF to IS-IS. Those on this list who are currently running IS-IS, do > you find better scalability and stability running IS-IS than OSPF? I > understand that this question is a lot more complex than a simple yes > or no since factors like design and routing policy will certainly > affect the protocols behavior. > > Any insights or experiences that you can share would be most helpful. > > Thanks, > > Daniel Evans > Alltel Communications Daniel, in short, we've found ISIS to be slightly easier to maintain and run, with slightly more peace of mind in terms of securitiy than OSPF. Performance and stability wise, no major difference that was noticable. For more information, see the talk by Dave Katz at http://www.nanog.org/mtg-0006/katz.html Also, AOL's experience in switching from OSPF to ISIS is covered at http://www.nanog.org/mtg-0310/gill.html the PDF on that page is actually an older version. The full version I used at NANOG is available at http://www.vijaygill.com/oi.pdf /vijay

4 3

Re: OSPF -vs- ISIS
by Fergie (Paul Ferguson) 21 Jun '05

21 Jun '05

Isn't that because Dave re-wrote all of the IS-IS code? ;-) - ferg -- vijay gill <vgill(a)vijaygill.com> wrote: Daniel, in short, we've found ISIS to be slightly easier to maintain and run, with slightly more peace of mind in terms of securitiy than OSPF. Performance and stability wise, no major difference that was noticable. For more information, see the talk by Dave Katz at http://www.nanog.org/mtg-0006/katz.html Also, AOL's experience in switching from OSPF to ISIS is covered at http://www.nanog.org/mtg-0310/gill.html the PDF on that page is actually an older version. The full version I used at NANOG is available at http://www.vijaygill.com/oi.pdf /vijay -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Re: OSPF -vs- ISIS
by Fergie (Paul Ferguson) 21 Jun '05

21 Jun '05

It is a dangerous thing when, in the course of engineering, you have a solution looking for a problem, instead of a problem looking for a solution. I'd say that the biggest benefit in using IS-IS over OSPF is the tuning of route metrics, but aside from that, I'd say that the two routing protocols are substantially similar enough to warrant close consideration of exactly what one would want bad enough to switch from one to the other. - ferg -- Erik Haagsman <erik(a)we-dare.net> wrote: On Tue, 2005-06-21 at 09:04 -0500, Dan Evans wrote: > Can anyone point me to information on what the top N service providers > are using for their IGP? I'm trying to build a case for switching from > OSPF to IS-IS. Why are you trying to build a case...? Would you already have operational benefit from switching and are you building a case round that and if not, why switch...? Switching IGP in a non-trivial network isn't something you'd want to do unless you've got a clear motive and it gives you some operational advantage... -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

MCI routing loop near Chicago
by James Couzens 21 Jun '05

21 Jun '05

MCI administrator(s): Whilst attempting to contact host '64.195.130.100' (NS1.USR.COM) From Net-Nation (TIER-1 peering with BIG PIPE, LEVEL 3, MCI, VAIX): 3 r1.netnation.com (64.40.105.1) 0.580 ms 0.716 ms 0.618 ms 4 122.ATM2-0.GW1.VAN1.ALTER.NET (209.167.46.101) 0.727 ms 0.898 ms 1.122 ms 5 0.so-1-0-0.XL2.VAN1.ALTER.NET (152.63.137.134) 1.518 ms 1.171 ms 1.150 ms 6 0.so-6-0-0.XL2.CHI6.ALTER.NET (152.63.65.126) 47.873 ms 48.239 ms 47.895 ms 7 POS7-0.GW6.CHI6.ALTER.NET (152.63.68.189) 47.759 ms 47.986 ms 47.879 ms 8 mci28259-gw.customer.alter.net (63.84.148.170) 50.134 ms 50.505 ms 49.439 ms 9 Serial4-8.GW6.CHI6.ALTER.NET (63.84.148.169) 49.412 ms 49.208 ms 49.800 ms 10 mci28259-gw.customer.alter.net (63.84.148.170) 51.736 ms 50.326 ms 50.194 ms 11 Serial4-8.GW6.CHI6.ALTER.NET (63.84.148.169) 50.191 ms 49.972 ms 50.192 ms 12 mci28259-gw.customer.alter.net (63.84.148.170) 51.314 ms 51.605 ms 52.499 ms 13 Serial4-8.GW6.CHI6.ALTER.NET (63.84.148.169) 54.37 ms 53.607 ms 54.81 ms For what its worth if someone from US Robotics is listening, neither of your two listed nameservers are reachable from Western Canada as tested from Net-Nation, the Shaw and Telus residential networks, and the Telus business network. Cheers, James -- James Couzens, Programmer http://libspf.org - ANSI C Sender Policy Framework library http://ses.codeshare.ca - Signed Envelope Sender, A comprehensive and simple solution to stopping SMTP forgery. Please review our work and find any flaws in our protocol.

3 3

RE: [NON-OPERATIONAL] Re: NANOG Evolution
by Hannigan, Martin 21 Jun '05

21 Jun '05

> -----Original Message----- > From: Steve Feldman [mailto:feldman@twincreeks.net] > Sent: Monday, June 20, 2005 8:34 PM > To: Hannigan, Martin > Cc: Daniel Golding; nanog(a)merit.edu; nanog-support(a)merit.edu > Subject: Re: [NON-OPERATIONAL] Re: NANOG Evolution > > [SNIP ] > I agree, this is an imperfect mechanism, but there was a desire > to get the process going well in advance of the next meeting. > Otherwise we would have to wait a few extra months. Also, note > that not all voters will be at any given meeting. All the broadcast mechanisms will be. [ SNIP ] > > [ dead horse ] > > > > Lastly, "6.2.1 Program Committee Membership and Selection " is > > not acceptable, IMO, for the group at large. It should be > normalized > > much like the Mailing List Admins. This disables the ability of the > > Steering Committee to lead. > > > > Ultimately, the SC is elected to represent the membership and > > carry out it's will and that should be uniformly actionable > > across the board in order for the SC to be taken seriously > > by the group and by Merit. > > I'm not sure what you mean here. It means that it doesn't make a lot of sense to handcuff the SC out of the gate on a supposition that they will do 'something bad' to the PC. Anyhow, it's a window dressing handcuffing. Looks like anyone can be removed with a 5 to 7 vote of the SC. You've all read the revised Charter, top to bottom? Kind of makes 6.2.1 ceremonial. It should be removed based on that alone. [ SNIP. It's procedural, not personal ] -M<

4 3

RE: [NON-OPERATIONAL] Re: NANOG Evolution
by Hannigan, Martin 21 Jun '05

21 Jun '05

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Daniel Golding > Sent: Friday, June 17, 2005 1:30 PM > To: Randy Bush; Betty Burke > Cc: nanog(a)merit.edu; nanog-support(a)merit.edu > Subject: [NON-OPERATIONAL] Re: NANOG Evolution > > > > Randy, > > People's employers are posted at > http://www.nanog.org/candidates05.html. > > It gets a bit complicated because some folks work at "infrastructure" > companies - collocation/peering or DNS (Mark, Bill, Josh, > Marty). It shouldn't be complicated. I think "members" are looking for Operator experience. I don't think it's too hard to make that easily discernable as long as it's fair. One thing that nags me a bit is we're not doing this at an actual NANOG meeting. Candidates don't get to discuss their qualifications and make a pitch to get elected. It's hard to determine if "someone" is suitable for the responsibilities if you cannot hear/see/get a feel for where they are coming from. This goes to leveling of the playing field. You may have a cruddy bio, but be a great candidate, and vice versa. How do you propose we get out the information as to why we should be elected to represent the group at large? [ dead horse ] Lastly, "6.2.1 Program Committee Membership and Selection " is not acceptable, IMO, for the group at large. It should be normalized much like the Mailing List Admins. This disables the ability of the Steering Committee to lead. Ultimately, the SC is elected to represent the membership and carry out it's will and that should be uniformly actionable across the board in order for the SC to be taken seriously by the group and by Merit. -M<

5 4

NANOG Evolution
by Betty Burke 21 Jun '05

21 Jun '05

Hello Everyone:> We are very happy to report the next steps in the evolution of NANOG are underway. We welcome your support and feed-back. The new NANOG charter is available at: http://www.nanog.org/charter.html changes in the new charter include: Section 5: added a parenthetical clause so the text now reads: "Anyone who has registered for a NANOG meeting in the previous two years (as of the opening date of voting) may vote in any matter which comes before the community for a vote." Section 6: moved two sentences to section 6.3: "No action may be taken by the committee unless at least four members of the committee are present. Those items on which the Steering Committee votes will be decided by absolute majority." Section 6.2.1 - old version: "Because a large Program Committee will be better able to handle the heavy workload, the Program Committee will consist of 16 members (plus one member appointed by Merit)." New version: "The Program Committee will consist of 16 members appointed by the Steering Committee plus one member appointed by Merit." ----- The candidates for the Steering Committee are: Joe Abley Randy Bush Christopher Chin Ron da Silva Vince Fuller Steve Gibbard Dan Golding Martin Hannigan Dorian Kim Mark Kosters Jared Mauch Chris Morrow William B. Norton Philip Smith Josh Snowhorn Dave Wodelet Lixia Zhang Further information found at: http://www.nanog.org/candidates05.html ------ Community members eligible to vote in the 2005 NANOG Steering Committee election are found at: http://www.nanog.org/voters05.html To qualify, you must have attended at least one NANOG meeting in the past two years, i.e., between fall 2003 (Chicago, NANOG 29) and spring 2005 (Seattle, NANOG 34). Email addresses will be used to authenticate voters during the election. Voters for whom Merit does not have an email address are marked with ***. If your name is marked, or if you're not listed and believe you should be, please send e-mail to nanog-support(a)nanog.org. ------ A new email list, nanog-elections(a)merit.edu, for discussion of the elections has been created. Merit will handle moderation of the new list per the aup found at: http://www.nanog.org/aup.elections.html (Everyone on nanog-futures is automatically subscribed, and we'll also subscribe all eligible voters for whom we have email addresses.) Information regarding the election process will be sent to this list is a few days. --------- Information regarding the NANOG list moderation committee is found at: http://nanog.org/listadmins.html --------- Lastly, very soon, Steve Feldman (current PC Chair) will be sending information regarding the new Program Committee members. --------- In summary, THANK YOU to so many for their support, extra time and assistance. Merit and the NANOG community are very grateful. As always, please feel free to send email or call if you have questions regarding this email or the NANOG evolution process. All the best!:> Betty Burke and Susan Harris Merit Network

6 6

RE: [NON-OPERATIONAL] Re: NANOG Evolution
by Hannigan, Martin 21 Jun '05

21 Jun '05

> -----Original Message----- > From: vijay gill [mailto:vgill@vijaygill.com] > Sent: Monday, June 20, 2005 9:06 PM > To: Hannigan, Martin > Cc: Daniel Golding; nanog(a)merit.edu; nanog-support(a)merit.edu > Subject: Re: [NON-OPERATIONAL] Re: NANOG Evolution > > > Hannigan, Martin wrote: > > > > > It shouldn't be complicated. I think "members" are looking > > for Operator experience. I don't think it's too hard to make that > > easily discernable as long as it's fair. > > Members aren't looking for Operator experience (sic). Members are > looking for talks that do not suck. > (sic) is a matter of interpretation, and, you already said the talks suck. The PC said they don't get enough talks. Some of the talks are going to be filler. -M<

3 2

LACNIC's new allocation from IANA
by Ricardo Patara 20 Jun '05

20 Jun '05

We apologize for duplicates. LACNIC received new IPv4 address blocks from IANA on last June 17th, and will start to make allocation from these new blocks in near future. The IP blocks allocated are the following: 189/8 and 190/8 We recommend the network administrators to revise and to adjust the filters they might have in place. For additional information about Internet Resources under LACNIC administration, please refers to: http://lacnic.net/en/registro Ricardo Patara LACNIC / RS Manager --

1 0

Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
by Joe St Sauver 20 Jun '05

20 Jun '05

Of course, there's already one application-level messaging protocol that relies extensively on arranged peerings: Usenet. Usenet doesn't rely on a *full* N-way mesh of arranged peerings, it relies instead on a core of fairly well interconnected "backbone" or "core" news sites who've agreed to do feeds with each other, as well as to feed downstream "leaf nodes" (either on a for-fee commercial basis, or gratis as part of a regional consortia or whatever). To receive traffic or originate traffic, a leaf node doesn't need to peer with every other news server, it just needs to do feeds with a couple of upstream core sites to insure that it has reasonable coverage and redundancy. Spam isn't much of a problem on Usenet anymore because peers who tend to have spam issues tend to clean them up or get depeered or shunned... There's no reason why one couldn't build a comparable model for mail, with the SMTP speciality service provider offering "SMTP transit" to a base of trusted customers. This comparatively small number of SMTP speciality provider would then maintain good relations ("peerings") with the comparatively small number of major ISPs. Oh wait -- there are a variety of folks who are already specializing in doing that sort of thing -- it's just that most folks don't need to buy that sort of service (yet). Regards, Joe St Sauver (joe(a)uoregon.edu) University of Oregon Computing Center

4 3