June 1996 - Test - lists.nanog.org

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

Re: critique of NANOG meeting
by Justin W. Newton 20 Jun '96

20 Jun '96

Well, I'm sure as hell not bringing a tie. At 04:19 PM 6/19/96 +0800, Vadim Antonov wrote: >How about a tie party? :) > >--vadim > >>From: Per Gregers Bilse <bilse(a)EU.net> > >>Bob is actually quite funny at times, I liked the thing about wearing >>a tie. Can we get somebody to send a reminder on the IETF announcement >>list, for people to bring ties and testboot their laptops before >>turning up in Montreal? > > Justin Newton Internet Architect Erol's Internet Services

3 2

Sprint filters (yes really)
by Sean Doran 20 Jun '96

20 Jun '96

-----BEGIN PGP SIGNED MESSAGE----- Please note that the changes to Sprintlink's filtering policies that Marc Hidalgo and I announced at NANOG have been implemented, and should be visible as BGP sessions with our external peers (MCI, ANS, Alternet, PSI et al.) reset over time. It is hoped that the changes won't be flawed, but any oddities would be nice to know about. The two and a half week delay in implementation is my own fault. Note that the policy is now: [allow none of the RFC 1597 et succ. reserved addresses] in 0/8-126/8, allow no subnets of historical As that were not announced in July 1995[*] 127/8-191/8, allow nothing longer than /16 [*] 192/8-205/8, allow nothing longer than /24 206/8-223/8, allow nothing longer than /19 195/8 [RIPE block, 12 dec 95], allow nothing longer than /19 [other RIPE and APNIC blocks that have begun being allocated from since July 1995 will also be filtered on the /19 boundary] The principal change is that we used to disallow /19s in 207/8-223/8 and 195/8, and this was not in line with the minimal allocation units performed by the three primary registries. Please also note that we have also already accumulated a couple of months of successful experience with differential filtering, and will be both tightening up the filtering in the newly unfiltered space and tweaking the currently-used values up and down. Very roughly speaking, the goal is that if you have a very long prefix (like a /24), and it flaps a couple times, you can go home for the day. If you do even the slightest bit of aggregation (into a /23, for example), then you are much less likely to be dampened in the face of minor flapping, and you will be dampened for less time. Once you have aggregated enough addresses to comprise a /18 or shorter prefix, you will be dampened with values very much in line with the default you get from Cisco's "bgp dampening" command. At the moment, you are much more likely to be dampened if you are NOT a Sprint customer. That is, the normal values for "bgp dampening" are in place if you have a customer connection to SprintLink or ICM. However we will be evaluating the engineering and operational effects that a similar policy with respect to SprintLink customers, as an effort to encourage some of our lazier customers to begin doing their own aggregation wherever possible. You may not be surprised that the success of this differential dampening experimentation has played a large role in the easing-up of our filtering policies. Sean. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey iQCVAwUBMcmkVkSWYarrFs6xAQEblQQAg60neKgLSGpQZ2e0n67MRjVNd+eLDSaJ Ceea+2bypM8V9QD6nTr6zEJ302qLrIK6b9e0lLmgFPpoUs1Rb3KDqv4ruAQKmkBo dDu5NxIAlG9b+qvXTuocPA81y4+zWKMOaFHCPFNksMIzhA19pRYLndiuJqRifiHn CQyAZGorrwQ= =uyTH -----END PGP SIGNATURE-----

1 0