October 2004 - Test - lists.nanog.org

Verio Houston issues?
by Pete Templin 20 Oct '04

20 Oct '04

Verio apparently had a power failure at their Houston TX POP, and has had routing problems ever since. Anyone have any better scoop on this? We're only receiving ~500 routes from them at this point. pt

1 0

RE: MPLS Book Recommendation
by Hannigan, Martin 20 Oct '04

20 Oct '04

The cisco book written by Eric Osborne is very good. Cisco Press. -M< -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations & Infrastructure hannigan(a)verisign.com -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Charlie Khanna - NextWeb Sent: Thursday, October 07, 2004 5:15 PM To: nanog(a)merit.edu Subject: MPLS Book Recommendation Hi, Can anyone recommend a good book on MPLS? I'm looking for something that will illustrate network design/implementation (including possible Cisco configs) with MPLS. Thanks! -Charlie

1 0

Re: BCP38 making it work, solving problems
by Fergie (Paul Ferguson) 20 Oct '04

20 Oct '04

Hmm, so let me figure this one out... Are you arguing against BCP38 implementation/filtering, or what? - ferg -- JP Velders <jpv(a)veldersjes.net> wrote: In most cases it will go like that, the minority of when it doesn't go like that, you start filtering / whatever, just like we do now. Regards, JP Velders -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

3 2

Re: BCP38 making it work, solving problems
by Paul Vixie 19 Oct '04

19 Oct '04

> > ... the first thing is, some nets who want the internet to work this > > way have to implement BCP38 in their own corner of the internet. > > then they have to start de-peering with nets who don't do it, and > > offer a better rate to customers who do it than to those who don't. > > then they have to de-peer with anyone who doesn't require their > > peers and customers to do it. then they have to refuse as customers > > anyone who won't do it. ... > > As it was "in the old days": first clean up your own act and then > start pointing at others that they're doing "it" wrong. > > It's a mentality I see very rarely amongst the larger ISP's who've > been part of that 'I' in their name since the very early beginning. i found out from verisign that big companies call something "innovation" if it hasn't been generally done before and if it immediately increases revenue. failing the "immediately increases revenue" part, no big company will do anything that hasn't been generally done before. unless their insurance companies or their government insists, that is. the same cfo's who are choking the life out of your backbone (equipment, staff, etc) are perfectly happy to pay a little more to get UL-listed refrigerators for the company's break rooms. i guess the grownups really are in charge? i'm pretty depressed at the lack of self regulation among the techiefolk. responses to BCP38 of the form "but my customer has a good reason to spoof" or "but my equipment can't do wire speed SAV" or "but BCP38 will not solve all DDoS problems single-handedly" are small minded, provincial, and wrong. ... it's just "but if man was meant to fly he'd have wings" all over again.

4 3

CFP : Special issue on interdomain routing in IEEE Network Magazine
by Olivier Bonaventure 19 Oct '04

19 Oct '04

Dear colleagues, A short note to inform you that the November/December 2005 issue of IEEE Network Magazine will be devoted to interdomain routing. The submission deadline is March 15, 2005 and you can find the full call for papers here : http://www.comsoc.org/pubs/net/ntwrk/special.html Best regards, Olivier Bonaventure, Anja Feldman, Lixin Gao, Tim G. Griffin and Z. Morley Mao

1 0

I-D on operational MTU/fragmentation issues in tunneling
by Pekka Savola 19 Oct '04

19 Oct '04

Hi all, I've written a very short (about 5 pages of meat) Internet-Draft describing the issues and operational approaches to the problems faced with doing tunneling in the network -- as these issues kept coming up again and again with IP-in-IP, GRE, L2TP, etc. The approaches may be different for passive monitoring ('wiretapping' etc.) and 'active' tunneling. The document is about to be IETF Last Called for Informational RFC, but prior to that, I'd like to solicit comments/feedback/review from the people here because I'm 100% sure a lot of people have been faced with these issues (we certainly have..). Please send comments to me by the end of this week, either on- of off-list, as you deem appropriate. Find it at: http://www.ietf.org/internet-drafts/draft-savola-mtufrag-network-tunneling-… Abstract Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided. This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

7 9

Enterprise Access Log Scanning Tools
by Cullen, Michael 19 Oct '04

19 Oct '04

Greetings all, Does anyone have (1) any experience, (2) any suggestions, or (3) an appropriate contact to these types of tools? The requirements include ACE and NT Domain access logs. Thank You, Michael Cullen Senior Security Engineer Technical Architecture, Policy and Web Services Universal Music Group (818) 777-4049

1 0

Philadelphia MCI/UU PoP?
by Dave Temkin 19 Oct '04

19 Oct '04

Does anyone know the address of the Philadelphia MCI/UU (legacy?) POP? Replies off list are fine. Thanks, -Dave

2 1

People being removed from the list and such
by Malayter, Christopher 19 Oct '04

19 Oct '04

It has come to my attention that recently several people have been censored from posting to the nanog@ list. I find it a bit unusual that from such an open discussion list that membership would be censored without notice and reason to the rest of the membership. I wouldn't normally be the one to post this, but the people who have been censored in some cases I believe to be extremely valuable people to the list. My question is this: When people are removed/censored, be it temporary or permanent, could we have a notice posted to the membership as to the person, reason, and duration? Also, I realize that this sounds odd, could we add an appeals process? The idea of a single person with unilateral control over such a group, without taking into consideration the needs and desires of the group, does not seem fair. I believe that there is need for recourse in this community for a person who is removed or censored unfairly. Regards, Chris Malayter TDS Telecom - Network Services Network Management and Operations chris.malayter(a)tdstelecom.com Phone: (608) 664-4878 FAX: (608) 664-4644

9 8

RE: Level 3 US east coast "issues"
by Niaz, Wajahat 19 Oct '04

19 Oct '04

Level3 had issues while upgrading the code on their Junipers. According to their tech support they have isolated those routers and things should be normal. Wajahat -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mike Callahan Sent: Tuesday, October 19, 2004 9:46 AM To: nanog(a)nanog.org Subject: RE: Level 3 US east coast "issues" Anyone have the latest update on this? We seem to still be experiencing routing issues from Level3 this morning and we never did get notification from them that the previously reported issue had been resolved. Thanks, Mike Callahan -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Grant A. Kirkwood Sent: Monday, October 18, 2004 12:15 PM To: nanog(a)nanog.org Subject: Level 3 US east coast "issues" Level 3 experiencing widespread "unspecified routing issues" on the US east coast. Master ticket 1086844. Anyone have more specific information? -- Grant A. Kirkwood - grant(at)tnarg.org Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED

1 0