March 1997 - NANOG - lists.nanog.org

Canadian Network Operators:
by Douglas Denny 17 Mar '97

17 Mar '97

This is of interest to all Canadian Internet operators. Re-distributed by request. -Doug -- PLEASE DISTRIBUTE -- Net '97: The 11th Annual Canadian Internet Conference June 22-25 Dalhousie University Halifax, NS CANADA Together on the Ocean / Voyageons Ensemble Net '97, vous invite a presenter en francais. ~~~~~~~~~~~~~~ SPONSORED BY: ~~~~~~~~~~~~~~ Cisco Canada Ltd CA*net networking Inc Bell Advanced Communications MT&T Advanced Communications Dalhousie University CANARIE Inc iSTAR Internetwork Inc ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CONFERENCE INFORMATION & REGISTRATION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Check out: http://net97.dal.ca/ Online Registration and Accommodations; Full Conference Information ~~~~~~~~~~~~~~~~ CALL FOR PAPERS ~~~~~~~~~~~~~~~~ Dalhousie University, in Halifax, Nova Scotia invites the Canadian networking community to your eleventh annual congress, on June 22nd to 25th. Net '97 will bring together the people who make the Internet work in Canada, to share knowlege, experiences and future plans in both the commercial and academic fields. This is a conference for Canadian Internet articifers; the people who design, build and maintain the net. A job which since the beginning of networking in Canada has been most closely linked with higher education and research. The past year has seen dramatic changes and Net '97 will involve both academic and commercial tracks. Extended abstracts outlining the proposed paper should not exceed 300 words. Please indicate which track, commercial or academic, you feel your paper would be most appropriate for. Papers will be published on the Web for two years, and CD-ROMs of the proceedings will also be available. ~~~~~~~~~~~ KEY DATES: ~~~~~~~~~~~ March 28: Receipt of abstracts April 11: Acceptance Notification June 1: Submission of full paper in machine readable form July 25: Submission of revised paper in machine readable form ~~~~~~~~~~ ENQUIRIES ~~~~~~~~~~ Please direct all correspondence regarding Net '97 conference to Net97(a)Dal.Ca. - 30 - -- Douglas A. Denny denny(a)rns.net Network Operations Specialist DIRECT: +1 416 443 7941 Rogers Network Services TOLL-FREE: +1 800 267 DATA

1 0

De-registration request
by Mirjam Kuehne 17 Mar '97

17 Mar '97

Dear Hank, Sorry for the delay, I am not on the nanog list anymore (it's hard enough to follow naipr ;-) Just to correct this: Fortunately you were not the first one who returned an AS number. Since we have many hostmasters working at the RIPE NCC the particular hostmaster you dealt with might not have been aware of this. We even make regular surveys to find out if networks are multihomed. Some people then realise that they don't need an AS number and return it. And the procedure is really easy: You just inform us that you don't need the numbers anymore and we take appropriate action. We are always happy to take AS numbers or address space back. Don't hesitate :-) Kind Regards, Mirjam Kuehne Manager Registraton Services RIPE NCC * -------- Forwarded Message * * Return-Path: owner-nanog(a)merit.edu * Date: Tue, 11 Mar 1997 07:36:48 +0200 (IST) * From: Hank Nussbacher <hank(a)ibm.net.il> * To: Paul A Vixie <paul(a)vix.com> * cc: nanog(a)merit.edu * Subject: Re: Class "B" forsale (fwd) * In-Reply-To: <199703110044.QAA22923(a)wisdom.home.vix.com> * Message-ID: <Pine.A32.3.95-heb-2.07.970311073419.71061F-100000(a)rex.ibm.net. * il> * MIME-Version: 1.0 * Content-Type: TEXT/PLAIN; charset=US-ASCII * Sender: owner-nanog(a)merit.edu * Status: RO * * On Mon, 10 Mar 1997, Paul A Vixie wrote: * * > > Yes, I know many (David and Geoff:-)) are probably calling me Pollyanna * > > right about now and it is true that most companies won't return it * > > if they think they can sell it. But I think having a procedure in * > > place to at least begin reclaiming addresses from those organizations * > > that are no longer in business can only help matters. * > * > I personally oversaw the return of four /16's recently, so I, at least, * > do not consider this to be Pollyannaism. * > * * When I returned an ASN 2 months ago to RIPE, I asked what the procedure * was to deallocate an AS object and return it to the pool of available * numbers. I was told there was no procedure since I was the first. :-) * * Hank Nussbacher * * * -------- End of Forwarded Message

1 0

Re: consistent policy != consistent announcements
by Vadim Antonov 17 Mar '97

17 Mar '97

Randy Bush wrote: >A normal condition of peering between consenting adults is that the peers >have consistent policy across all points where they peer. [example of a quasi-consistent scenario skipped] >Am I being unfair to my peers? Would they be justified in making a stronger >requirement than 'consistent' policy? What requirement would be reasonable? There are three quasi-answers: 1) it's ok with consent of parties involved (i.e. you may want to coordinate fancy policies with peers) 2) generally speaking, BGP path length is too blunt an instrument. More fine-grained control is needed to allow peers to fine-tune balance of their interests. I'm sorry to be too naive, but i'm repeating that for years and nobody seems to agree that BGP needs real metrics. How come? 3) on a phylosophical level, all involved parties should have a way to control destiny of routes, to a some extent. Right now, it's either control local to the destination (local preferences), or control by adjacent neighbour (MEDs). There's no way to extend it further (save for as-replication kludgery) or to combine local and remote metrics in any meaningful way. --vadim

4 3

[Fwd: Software Forum Dinner Mtg., Wed. Mar. 19, Bob Metcalfe]
by dan 17 Mar '97

17 Mar '97

Just ran accross this on ba.seminars, thought it may be of interest to some of you. ;) dc > > SOFTWARE FORUM (Palo Alto CA) > Dinner Meeting, Wednesday March 19 > > Bob Metcalfe will review his early 1996 prediction of imminent > Internet collapse, and will identify what current trends will become > dominant in the future. > > Bob has a Ph.D. from Harvard, led the development of Ethernet, founded > 3Com Corporation, was an InfoWorld columnist for several years, and is > now VP of technology for IDG, a leading IT research firm. He is an > entertaining and provocative speaker. Come and ask your own questions! > > Where: 4249 El Camino Real, Palo Alto (call Software Forum office > for directions) > > Date: Wednesday, March 19, 1997 > Time: 6:30 p.m. - Cocktail hour, 7:00 p.m. - Dinner > > Price: $25 members, $40 non-members > > Reserve: Software Forum voice mail (415/854-8298) > > Info: Software Forum office (415/854-7219) > http://www.softwareforum.org > > ********************************************************************** > For these announcements by email, send mail to majordomo(a)netcom.com, > with any subject, and with this text: subscribe software-forum-dinner > ********************************************************************** > > Software Forum, started in 1983, is a Silicon Valley based non-profit > organization dedicated to software professionals, with over 900 > members. It informs and educates its members on all facets of the > software industry -- ranging from technical innovation to product > development, marketing, and sales. The group offers professionals a > sense of community and is a valuable forum for exchanging ideas. > > Software Forum also sponsors 13 special interest groups, which meet > once a month: UNIX, C++, Business Operations, Delphi, Games & AR > Developers, International, Internet, Java, Marketing, Multimedia, > Visual Basic, VMRL, and Windows.

2 1

Information Week article
by Hank Nussbacher 17 Mar '97

17 Mar '97

Net Services Rated -- Startup measures user access times http://www.techweb.com/se/directlink.cgi?IWK19970310S0043 Does anyone know where these stats can be seen online? Thanks, Hank

2 1

GRIDNET wake up
by Randy Bush 16 Mar '97

16 Mar '97

Dear GridNet: Mail to the contacts in your whois data bounces. So we will make this a public plea: o Fix your whois data. o Please stop the SNMP probes from 206.80.163.6 to our routers. As they get no data as you do not know our community string, the continual repition could be interpreted as a denial attack. rady

1 0

Re: consistent policy != consistent announcements
by Danny McPherson 16 Mar '97

16 Mar '97

> Peers of R may still receive routes with different as-paths, but > as-path lengths and origin codes (which matter for selection) should > at least be the same for the most part, ever do a "sh ip bgp inconsistant-as" in a cisco? -danny

1 0

Re: consistent policy != consistent announcements
by Jessica Yu 15 Mar '97

15 Mar '97

If a provider/AS does not have the policy of dumping hot potatos to other peers for the traffic to its customers who happen to multihome to those peers. Then there is a simple way to do it. They can have policy of always favor its own customer routes over the routes learned from other peers. This will avoid the inconsistent announcement by eliminating the cases that some part of the AS favors routes M from it's customer and other part favors M from another peer, thus announce consistent routes to other peers. It's very easy to manage this policy. Just assign lower (less favored) local_pref to routes learned from peers than those learned from customers. It's AS based. By using the default local_pref value, one only need to assign a lower than default local_pref value to the peer AS at border routers. A good side effect of this policy is that your customers routes will be protected from being blackingholed from careless ISPs leaking/advertising your customers routes but have no way to reach them. --Jessica ------- Forwarded Message Return-Path: owner-nanog(a)merit.edu Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by cannes.aa.ans.net (8.8.5/8.8.3) with SMTP id QAA24798 for <jyy(a)cannes.aa.ans.net>; Thu, 13 Mar 1997 16:58:11 -0500 (EST) Received: by interlock.ans.net id AA25369 (InterLock SMTP Gateway 3.0 for regional-techsers(a)ans.net) Thu, 13 Mar 1997 16:57:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 13 Mar 1997 16:57:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 13 Mar 1997 16:57:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 13 Mar 1997 16:57:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 13 Mar 1997 16:57:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 13 Mar 1997 16:57:00 -0500 Message-Id: <v03101919af4e08805b01(a)[152.160.213.42]> In-Reply-To: <CMM.0.90.2.858281493.vaf(a)valinor.barrnet.net> References: Your message of Thu, 13 Mar 1997 10:46:06 -0500 (EST) Mime-Version: 1.0 Date: Thu, 13 Mar 1997 16:41:41 -0500 To: Vince Fuller <vaf(a)valinor.barrnet.net> From: "John G. Scudder" <jgs(a)ieng.com> Subject: Re: consistent policy != consistent announcements Cc: Sean Donelan <SEAN(a)sdg.dra.com>, nanog(a)merit.edu Sender: owner-nanog(a)merit.edu Content-Type: text/plain; charset="us-ascii" Content-Length: 2715 At 11:31 AM -0800 3/13/97, Vince Fuller wrote: >Well, if that "candidate path" is, in fact, one of Randy's customer, then >I would expect him to "cold-potato" route toward it. One would think that >to be part of the service that his customer is purchasing. I think that his internal routing policy and service to his customer is really irrelevant to the question at hand, except insofar as its side-effects affect you. >I certainly >shouldn't have to do "cold-potato" routing to his customer, as that customer >isn't purchasing anything from me. Ah, I finally see the problem. In essence, Randy's (announcement) policy assumes that a destination is either in the set of customer routes OR the set of peer routes, but not both. But in this case we have a destination which is in both. The side-effect ends up making you "cold-potato" route to destinatons in the (customer + peer) intersection. The question is, does it make sense for a destination to be considered to be in both sets? If "peer" is supposed to mean "not-customer" then the answer is probably no, there is (should be) no intersection between "customer" and "not-customer". If this is right, the problem is that sometimes the AS path is an overly blunt instrument to determine the customer-ness of a route. In the case where using the AS path doesn't allow the route to be categorized correctly, the only way *I* can see of fixing it is using manual policy (sorry). Presumably this could be done with a minimum of pain by something like (assumes M should properly be categorized as "customer"): (at router peering with customer C in Randy's example): write "customer" community onto all routes from C (at router peering with peer P in Randy's example): write "customer" community onto all routes from (P M) write "peer" community onto all other routes from P (at routers sending routes to external neighbors) send routes with "customer" community to all peer routers send routes with "peer" community to all customer routers send routes with "customer" community to all customer routers The special-casing is limited to the guy who peers with P, who has to decide to write "customer" onto (P M) routes. Presumably one could (semi) automatically detect when a new special case is needed by gathering routing table snapshots from border routers from time to time, and finding routes which are colored inconsistently (identical destinations, different communities). Regards, - --John - -- John Scudder email: jgs(a)ieng.com Internet Engineering Group, LLC phone: (313) 669-8800 122 S. Main, Suite 280 fax: (313) 669-8661 Ann Arbor, MI 48104 www: http://www.ieng.com ------- End of Forwarded Message

5 6

Re: consistent policy != consistent announcements
by Vince Fuller 14 Mar '97

14 Mar '97

add a peer P to your first example. if P peers with you at Point1 close to A's connection and again at a Point2 close to B's connection, then P will hear M's prefixes at Point1 as "R A M" and at Point2 as "R B M". but because the AS path length is equal, they'll still be able to do closest exit for M's prefixes. If that were happening, then we'd consisder the routes to be consistant, at least for shortest-exit purposes. What we are seeing, though, is "R A M" at Point1 and nothing at Point2, likely because Randy doesn't consider "R B M", received from one of his peers, to be a customer route. the tone of the "consistent route" policy is to keep one provider from having to carry packets cross-country in both directions: Full agreement. in this example P does not have to do that In your example, you are correct. But your example doesn't match the situation that Randy is describing. --Vince

5 6

Blacklist of spammers?
by Dave O'Shea 14 Mar '97

14 Mar '97

Not to start another "discussion" of mailspamming again, but I seem to recall that someone out here has a BGP update containing known spammers. Having had to update my &^% router twice today to block induhvidual spammers, I don't mind throwing my hands up in disgust.

3 2