- Test - lists.nanog.org

Re: Withdrawls and announcements attempt 2
by avg＠postman.ncube.com 21 Jun '96

21 Jun '96

The 30 second figure sounds pretty much like the good ol' line flap with default cisco keepalive. I was bothering cisco folks about making static routes persistent by default for quite a while. Although there's a workaround very few people actually bother to use it thus causing bouncing tail links to produce route flap. My suspiction is that this kind of flap accounts for no less than 90% of the total. Another probable contributor is RIP (shouldn't we declare it RIP already?) Most network administrators never heard of a simple maxim -- "Never use dynamic routing when you have a single path". As a result most LANs are plagued by RIP with no reason whatsoever (and many of them inject their IGP routes into BGP!) The lack of any meaningful clock source negotiation and idiotic defaults in CSU/DSUs is a major source of rapid link flap, too. It seems that most (if not all) equipment vendors simply don't have any clue of what effect their design choices have in the real world. --vadim

2 1

Re: My InfoWorld Column About NANOG
by John Curran 21 Jun '96

21 Jun '96

At 11:31 6/21/96, Bob Metcalfe wrote: >... >A few of you missed one point at least. I am NOT suggesting that any of >YOU start wearing suits, especially if you find them uncomfortable, or that >they make a statement you are not willing to make -- none of that, no -- >good engineers are too valuable to overdress. I am suggesting that more of >the kind of people who ALREADY wear suits should start paying attention to >the important work NANOG is attempting and start attending your meetings so >they can pitch in on the non-engineering aspects of operating the Internet. >Is that clearer now? Bob, I believe that you'll find quite a few folks "concerned with the non-engineering aspects of operating the Internet" amongst the attendee list of each NANOG and IEPG meeting. There is a great deal of activity in trying to scale the current Internet, but it doesn't always happen via the group presentations. One of the disadvantages of the decentralized nature of the Internet is that different organizations have different views on the best way to move forward; I'm not certain that a more centralized model can respond to change as quickly as we've accomplished to date. Are there particular issues that you think should be addressed at NANOG and/or IEPG? Both organizations have a fairly open policy with respect to agenda items and I imagine that your suggestions would be most welcome. >By the way, there are reports from two days ago that 400,000 people lost >their Internet access for 13 hours. Sounds like an outage approaching >"collapse." An interesting characterization... you'd definitely need to talk to NETCOM to determine if it was a "collapse" as opposed to a "serious event" or just a "typical failure mode". >Was that just a Netcom thing that NANOG has no interest in? >Netcom is not talking very much about what happened. Any >clues/facts out there? Were any NAPs involved? Again, NETCOM would be the authoritative source for such info... Reuter's June 19th coverage noted that the problem was related to a problem with a routine change to the "routing table". I will note that operating a large Internet backbone requires availability of staff with very specialized skills in both Internet routing and high-speed networking, and all Internet service providers face quite a challenge in maintaining such staff. This is a risk factor to Internet growth and stablility that receives little attention but nevertheless is quite real. /John p.s. Bob - It's possible that not all NANOG folks have a strong interest in this thread; have you considering creating a mailing list to host a discussion on the Internet's "imminent collapse"?

2 1

Re: My InfoWorld Column About NANOG
by sob＠academ.com 21 Jun '96

21 Jun '96

Sean writes: > Besides, I find that NANOG is overly USA-American-centric enough without > spending lots of time discussing matters that have little to do with reality > in other parts of North America. This is an interesting comment. I have always found it interesting that NANOG has such a large contingent attending from other parts of the world. I guess we both have our distinct perceptions about NANOG. That's not a good thing or a bad thing. Just a fascinating difference in perception. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: Withdrawls and announcements attempt 2
by Steven J. Richardson 21 Jun '96

21 Jun '96

Yeah, that's essentially what cisco said, though I'd guess that you ought to be able to at least not propagate the withdraw back to the peer who sent it to you... But that's just my opinion. Steve R./Merit == >From nanog-owner(a)merit.edu Fri Jun 21 11:26:41 1996 >Received: from merit.edu (merit.edu [35.1.1.42]) by home.merit.edu (8.7.5/merit-2.0) with ESMTP id LAA03178; Fri, 21 Jun 1996 11:26:39 -0400 (EDT) >Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id LAA16611 for nanog-outgoing; Fri, 21 Jun 1996 11:20:52 -0400 (EDT) >Received: from chops.icp.net (chops.icp.net [199.0.55.71]) by merit.edu (8.7.5/merit-2.0) with ESMTP id LAA16603 for <nanog(a)merit.edu>; Fri, 21 Jun 1996 11:20:31 -0400 (EDT) >Received: by chops.icp.net id <20689>; Fri, 21 Jun 1996 11:20:23 +0100 >From: Sean Doran <smd(a)icp.net> >To: justin(a)erols.com, nanog(a)merit.edu >Subject: Re: Withdrawls and announcements attempt 2 >Message-Id: <96Jun21.112023+0100_edt.20689+60(a)chops.icp.net> >Date: Fri, 21 Jun 1996 11:20:18 +0100 >Sender: owner-nanog(a)merit.edu >Precedence: bulk >Status: R > >Keeping track of the state of who got announced what is likely >to be a very very very bad idea for busy BGP talkers carrying >today's amount of NLRI and instability. > >There are some hacks around the simplistic "if it's in my RIB, >I have to propagate withdrawals to all my neighbours" for some >cases, but a more comprehensive fix would require some Thinking. > >This should probably get migrated over to the BGP list. > > Sean. >

1 0

Re: Withdrawls and announcements attempt 2
by Sean Doran 21 Jun '96

21 Jun '96

Keeping track of the state of who got announced what is likely to be a very very very bad idea for busy BGP talkers carrying today's amount of NLRI and instability. There are some hacks around the simplistic "if it's in my RIB, I have to propagate withdrawals to all my neighbours" for some cases, but a more comprehensive fix would require some Thinking. This should probably get migrated over to the BGP list. Sean.

3 2

Re: Withdrawls and announcements attempt 2
by Sean Doran 21 Jun '96

21 Jun '96

| There are however vendors out there that do exactly what you described | above and can therefore change policies and have them take effect | without having to take down a BGP session. Like cisco, for example, with the new soft reconfiguration stuff. C'mon Marten, I expect better than this type of marketing crap from you. | And they only withdraw a | prefix if they sent an update for it in the first place. -> BGP list please. Sean.

2 1

Withdrawls and announcements attempt 2
by Justin W. Newton 21 Jun '96

21 Jun '96

I forgot to put my message in here... Here it was. I'll wake up one of these days. Ok, this is probably obvious, and may have been thought of by many of you before, but here are some thooughts. Comment if you'd like... Ok, the huge number of withdrawls with respect to announcements has to do with the fact that withdrawls of routes are made to a peer even if the announcement of that route was never made to the sepcified peer. (Or so conjectured Craig in his talk). At first I was wondering why they had such a thing written into the RFC (i.e. why am I withdrawing a route that I never announced to someone, it seems like a horrible waste), but in a blinding flash of the obvious while I was sitting outside having a cigarette it came to me.... Route map filters. Well, ok, how much more obvious can you get you ask? Its /a little/ more complex than that. The RFC does /not/ call for closing down a BGP session when you change your route filters. Cisco's have to do this, but its not part of the RFC. So, if I, for the sake of argument, added a new filter /after/ I made an announcement to someone I would have to somewhere keep track of the fact that I made the announcement. It seems to me that this could get to be a bit memory intensive (keeping track of the state of every announcement made to every peer). This leads me to wonder whether if we had infinite memory (just for the sake of argument), if it would be more processor intensive to keep track of all of your announcements or if the overhead invloved in dealing with withdrawls that don't affect me is less. Justin Newton Internet Architect Erol's Internet Services

5 4

Withdrawls to announcements ratio
by Justin W. Newton 21 Jun '96

21 Jun '96

Justin Newton Internet Architect Erol's Internet Services

1 0

Re: My InfoWorld Column About NANOG
by Sean Doran 21 Jun '96

21 Jun '96

| I am suggesting that more of | the kind of people who ALREADY wear suits should start paying attention to | the important work NANOG is attempting and start attending your meetings so | they can pitch in on the non-engineering aspects of operating the Internet. I noticed or was introduced to marketing folks and legal counsel from no less than four networking corporations at the D.C. NANOG. I think you will find that the impression that folks in suits are neither aware of NANOG/EOF/APRICOT/IEPG nor present at some of the meetings is somewhat illusory. Looking at the people who are quietly subscribed to the NANOG list might also be enlightening. I agree with you that there is not much "pitching-in on the non-engineering aspects", however most of these people are senior enough to know that discussing legal or economic matters in a conference that is full of engineers is often less than very productive. Besides, I find that NANOG is overly USA-American-centric enough without spending lots of time discussing matters that have little to do with reality in other parts of North America. We have enough to talk about wrt just building an Internet that can continue to sustain the huge growth we've been seeing on an engineering level -- and this is of relevance to every Internet engineer everywhere in the world -- that diluting the list and the conference with other matters strikes me as fundamentally unwise. Sean.

1 0

Re: Sprint NAP
by Peter Lothberg 21 Jun '96

21 Jun '96

> > Peter Lothberg <roll(a)stupi.se> writes: > > > > > > SPRINT NETWORK ACCESS POINT (NAP) > > TERMS AND CONDITIONS > > .... > > > > 6. IP Address Assignment > > > > The customer shall receive his IP address assignment(s) from Sprint. Any > > address(es) provided by Sprint shall remain the property of Sprint ... > ^^^^^^^^^^^^ > Address ownership .... what a concept. > Although this is doing the right thing, the wording is dubious. > > Daniel 1. From a technical standpoint, it's likely to hurt the NAP stability if people start to move host adresses away, and I don't think they would be that usable elswhere in the network. 2. I have absolutely nothing to do with the document, I just turned into a readable format, as it seemed to be of general interest what the NAP terms and conditions where. 3. Where are the other NAP's terms&conditions? --Peter

2 1