- Test - lists.nanog.org

Re: OSPF -vs- ISIS
by Eric Gauthier 22 Jun '05

22 Jun '05

On Tue, Jun 21, 2005 at 03:16:06PM +0100, Richard Dumoulin wrote: > Hi Eric, what's the reason for migrating to ISIS? There are currently a few projects that we're doing which prompted us to take a look at how we're doing routing, both IGP and EGP. We're altering our border connectivity by spreading our multiple commodity Internet and Internet2 peers across multiple routers that connect into our core at multiple locations. As a result, we're likely to bring iBGP into our core and, clearly, this is going to alter our IGP setup. We're also looking into MPLS layer 2 VPNs to solve certain traffic classification issues (e.g. limiting I2 access, allowing "guest wireless" etc), which also means that we'd likely need to make modifications to our IGP/EGP setup. Though we filter OSPF multicast traffic, we wanted to add in MD5 passwords to our neighbors. We're deploying IPv6 within our campus, so we needed to look for an IGP to support this. Since we're going to have to make changes, some significant, to our IGP setup (currently multi-area OSPF) no matter what, we felt it made sense to review our options. It looks like IS-IS and OSPF are pretty much the same in terms of functionality. IS-IS, though, looks like it handles IPv6 networks more efficiently, its area scheme seems to match a little more to our topology, and the "security' element (i.e. you can't inject packets) of the adjacencies seems interesting. Also, as I said, we're likely going to move to an iBGP-based core, which seems to run parrallel to what service providers are doing, so I have to admit that "follow the leader" also played into the decision as larger ISP seem to be doing the iBGP/IS-IS combo. Eric :)

1 0

IANA IPv4 allocations and bogon updates: 74/8, 75/8, 76/8, 189/8, 190/8
by Rob Thomas 22 Jun '05

22 Jun '05

-----BEGIN PGP SIGNED MESSAGE----- [ Apologies to those of you who receive this note in multiple forums. ] Hi, all. The numerous Team Cymru bogon projects have been updated as of 17 JUN 2005 to reflect the following IANA allocation made on 17 JUN 2005: 074/8 Jun 05 ARIN (whois.arin.net) 075/8 Jun 05 ARIN (whois.arin.net) 076/8 Jun 05 ARIN (whois.arin.net) 189/8 Jun 05 LACNIC (whois.lacnic.net) 190/8 Jun 05 LACNIC (whois.lacnic.net) IANA allocations change over time, so please check regularly to ensure you have the latest filters if you are not using the bogon BGP feed(s). We do announce updates to the bogon projects to sundry lists, such as the bogon-announce list. We can not stress this point strongly enough - these allocations change. If you do not adjust your filters, you will be unable to access perhaps large portions of the Internet. Worse yet, you may end up blocking access for people who transit through you. Please do not apply any filters or blocks to your network without carefully considering the ramifications of doing so. As a point of reference, the Team Cymru master Bogon Reference Page can be found here: <http://www.cymru.com/Bogons/> A quick summary of the documents and projects that have been updated include the following: HTTP The Bogon List - <http://www.cymru.com/Documents/bogon-list.html> The Text Bogon Lists - <http://www.cymru.com/Documents/bogon-bn-nonagg.txt> - <http://www.cymru.com/Documents/bogon-bn-agg.txt> Secure BIND Template - <http://www.cymru.com/Documents/secure-bind-template.html> Secure IOS Template (Cisco) - <http://www.cymru.com/Documents/secure-ios-template.html> Secure BGP Template (Cisco) - <http://www.cymru.com/Documents/secure-bgp-template.html> Secure JUNOS Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-template.htm> Secure JUNOS BGP Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-bgp-template.htm> Ingress Prefix Filter Templates, Loose and Strict (Cisco) - <ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter- Templates/> Ingress Prefix Filter Template, Loose (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-loose.htm> Ingress Prefix Filter Template, Strict (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-strict.htm> BGP Bogon route-server for AUTOMATED updates of bogon filters - All bogon route-server peers have already received the appropriate BGP prefix updates. - <http://www.cymru.com/BGP/bogon-rs.html> RADb fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#radb> RIPE NCC fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#ripe> DNS Bogon (bogons.cymru.com) zone - <http://www.cymru.com/Bogons/index.html#dns> Monitoring Bogon prefix monitoring - <http://www.cymru.com/BGP/robbgp-bogon.html> Bogus ASN monitoring - <http://www.cymru.com/BGP/asnbogusrep.html> Please feel free to contact Team Cymru <team-cymru(a)cymru.com> with any comments, questions, or concerns. Thank you for your continued support. Rob, for Team Cymru. - -- Rob Thomas http://www.cymru.com Shaving with Occam's razor since 1999. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQCVAwUBQrjLPlkX3QAo5sgJAQFHwAP/Z8KrLp9id6PD51KNEjAlveJCxRnvP4ev RofqRMex1SB5itogkB4O6JmrpSqIjqgM2GsnAUREZr5/r2ekdAZwejT85zHftl92 3ExvEec3P2PVDdfWF5v9TSVWfzwwbMW2HWwymzUYT7klWpjblcUUPdAWl+khD+FU /C8cCA2b8qk= =JvMq -----END PGP SIGNATURE-----

1 0

Re: Email peering
by Ben Hubbard 21 Jun '05

21 Jun '05

Michael.Dillon(a)btradianz.com said: > That's strange because you just finished describing how > SOME companies are already engaging in email peering on > a piecemeal basis. And how these companies ARE finding > this to be beneficial in reducing costs. So please explain > why my suggestion about widespread email peering agreements > won't work? Because I don't think "some companies" == "the entire population of email users", or even a sizable (ie widespread) part of that population. A large number of people are fine with the current system, and thus won't pay more for something else. Me, for example. Those who are unhappy will pay more for a better solution, and some small number with really deep pockets may be at that point where they will pay for something like "business class" email, in addition to the "tourist class" email they already have. You seem to repeatedly describe a solution that becomes so big that it (at least substantially) replaces 25/SMTP. That's what I don't think will work, or is needed. > And please don't suggest that webs of trust are not > scalable. Given the techniques of scaling that we have > in the 21st century, I simply don't believe that. I don't think either are relevant to this discussion. In the utility model you seem to talk about (and that I was talking about) all you care about is the provider. If you contract with them for traceable, trusted spam free email, and they give you something less than that, they pay a penalty. The utility knows, and has a contractual relationship with, each endpoint, and presumably can keep track of traffic in its own network. Problem solved. And the whole thing doesn't need to scale, because there are a severely limited number of companies that would be willing to pay the costs for such a service. But they are out there, and one might be able to make a business out of it. Best, Ben

3 2

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