- Test - lists.nanog.org

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

Re: critique of NANOG meeting
by Michael Dillon 20 Jun '96

20 Jun '96

On Thu, 20 Jun 1996, Arun Welch wrote: > Or get a clip-on tie. Even works with t-shirts. Good idea. If British barristers are required to wear a wig and black robes in order to plead before the court, why can't Merit supply clip-on ties and suit jackets to NANOG presenters? I think it makes just as much sense as Bob's complaints, eh wot? Michael Dillon ISP & Internet Consulting Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael(a)memra.com

1 0

Re: Sprint NAP
by salo＠msc.edu 20 Jun '96

20 Jun '96

> To: Peter Lothberg <roll(a)stupi.se> > Cc: "nanog" <nanog(a)merit.edu> > Subject: Sprint NAP > From: Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> > Date: Mon, 17 Jun 1996 10:04:26 +0200 > > > 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. Actually, I believe that the addresses in question are _host_ addresses, (for devices directly attached to the Sprint NAP). I don't quite know what someone would do with a Sprint NAP host address if they "kept" it. You are correct that the language seems rather emphatic to networking types, but it probably works well for the lawyers. -tjs

2 1

Re: critique of NANOG meeting
by Marc E. Hidalgo 20 Jun '96

20 Jun '96

If I get the time to find it, I think I've got just the right tie.... see y'all in Montreal. Marc > > HINT: Get somebody to tie the tie and then have it sewed together or > > something so it doesn't accidentally come undone. > > > > Or get a clip-on tie. Even works with t-shirts. > > ...arun > --------------------------------------------------------------------------- > Arun Welch 5000 Arlington Centre Blvd > Lead Software Engineer Columbus, OH 43220 > CompuServe awelch(a)csi.compuserve.com >

1 0