- Test - lists.nanog.org

Re: Routing wars pending?
by Sean Doran 15 Nov '95

15 Nov '95

Hm, routing wars. Fun stuff. Expect much heat on this shortly... :( Essentially, the point-of-appeal would probably be the IEPG or NANOG mailing lists, and who would get believed would probably get worked out after some protracted flameage, consultations with lawyers, and arguments about how routing registry technologies will save the planet from routing wars, pollution, and too-strong coffee. My own personal advice wrt people who are thinking of using others' address space without permission is pretty simple: don't do it, you'll lose. Sean.

2 1

Re: Motion for a new POST NSF AUP
by Robert Moskowitz 15 Nov '95

15 Nov '95

At 10:56 AM 10/16/95 +0100, Havard.Eidnes(a)runit.sintef.no wrote: >> Another suggestion was that SMTP headers always contain the >> IP address. I've seen this in quite a few mailers already. >> All we need is a slight modification to the SMTP Receipt >> standard. This could be a Best Current Practice, quickly >> published! > >Hm, this is already covered. RFC 1123 says: > > 5.2.8 DATA Command: RFC-821 Section 4.1.1 >... > * The FROM field SHOULD contain both (1) the name of the > source host as presented in the HELO command and (2) a > domain literal containing the IP address of the source, > determined from the TCP connection. Big deal. Since it is only SHOULD many mailers, like CDC's MAIL*Hub profess not to support it, as it is not a MUST... Robert Moskowitz Chrysler Corporation (810) 758-8212

1 0

Re: AS690 advisory update
by ser-rr＠ser.bbnplanet.net 14 Nov '95

14 Nov '95

Oh, and sorry about that spam. *cringe* _k

1 0

Who has OC3 backbones?
by Michael Dillon 14 Nov '95

14 Nov '95

On the IAP list the question recently came up whether any NorthAm NSP's currently have operational OC3 backbones (or portions thereof). I would appreciate it if somebody would post their current status (and future rollout schedules?) regards OC3 on either this list or on iap(a)vma.cc.nd.edu To subscribe, send subscribe IAP to the address listserv(a)vma.cc.nd.edu Thanks. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael(a)memra.com

1 0

Re: AS690 advisory update
by The BBN NACR Account 14 Nov '95

14 Nov '95

Greetings- Your request has been received by our IP addressing staff, and will be attended to as soon as possible. The staff member in charge of your request will notify you when it is completed. Due to the volume of mail processed, it may take up to one business week to complete your request. Requests for new IP addresses may take longer to process. If you have a question about your request, or need to refer to it later, your NACR ticket number is SER1114-162451. Please include this id in any mail pertaining to this request. Additionally, if you are looking for any of our forms, please check our ftp server at ftp://ftp.ser.bbnplanet.net/pub/forms -NACR

1 0

Re: AS690 advisory update
by ser-rr＠ser.bbnplanet.net 14 Nov '95

14 Nov '95

What happens if policy changes for those AS'es? i.e., AS279 decides to no longer route to AS690 via AS3561, but changes to route through AS701. (*grin*) How is new policy to be determined, either for new ASes, or for existing ones that drastically change their routing policies? _k > Elliot, > > Ignore the advisory. If AS2 is the origin, we will route traffic > for that particular prefix/masklen using the most common policy > already in place for routes in AS2. > > If the common policy is for us to send traffic destined for AS2 > via our peer AS1, we will continue to do so for the new prefix/masklen. > > Steve > > > > > > After this time, AS690 advisories will be ignored. Policy toward > > > routes registered in the IRR will be based solely on origin AS. > > > The origin AS will be expanded to the set of route objects registered > > > for that origin AS; the resulting list of prefixes will be used in > > > generating router configurations, as today. > > > > in the case of AS#1 routing AS#2, suppose AS#2 sent in the route object > > and list themselves as the origin, and put AS#1 in the advisory. in the > > new scenario, will ANS now only allow routes coming via the ASN in the > > ORIGIN field? i.e. will AS#2 have to change the ANS in the origin field > > to AS#1 so ANS knows where to look for for the routes? > > > > - elliot alby/sprintlink implementation > >

2 1

Re: AS690 advisory update
by The BBN NACR Account 14 Nov '95

14 Nov '95

Greetings- Your request has been received by our IP addressing staff, and will be attended to as soon as possible. The staff member in charge of your request will notify you when it is completed. Due to the volume of mail processed, it may take up to one business week to complete your request. Requests for new IP addresses may take longer to process. If you have a question about your request, or need to refer to it later, your NACR ticket number is SER1114-160833. Please include this id in any mail pertaining to this request. Additionally, if you are looking for any of our forms, please check our ftp server at ftp://ftp.ser.bbnplanet.net/pub/forms -NACR

1 0

Re: Attempt to summarize Links on the Blink
by Dave O'Leary 13 Nov '95

13 Nov '95

Various responses included below. >From: Avi Freedman <freedman(a)netaxs.com> >Subject: Re: Attempt to summarize Links on the Blink >To: cook(a)cookreport.com >Date: Mon, 13 Nov 1995 11:16:14 -0500 (EST) >Cc: nanog(a)merit.edu > >> I would like to try to understand better where this discussion seems to >> have come to rest. Yesterday the suggestion was made that the major >> providers add more bandwidth to their backbones. There seemed to be no >> assertion as to how this could be done. >> >> 1. OC-3 is not yet routable on backbones. Is that correct? > >Well, I was told that the Cisco AIP card can talk point-to-point to another >AIP card at OC-3 speed using either HDLC or PPP. It is true that AIPs can talk back to back through an OC3 link, however it doesn't use PPP or HDLC, just sending and receiving cells (i.e. std ATM, just no switch). So you get 155 Mb/s minus the ATM overhead, or about 130 Mb/s (depending on what you count as data, type of traffic, etc. >> 2. What is the routing impact of parrallel T-3s? Or the creation of >> mesh of T-3s? I have the impression that this is not feasible because it >> would expand the routing tables unacceptably or because of the questions >> of how you would load balance among them?? > >If data can be routed on parallel T3s on a per-connection basis so that >there isn't a scrambling of ordering of packets per connection, then some >benefit is achived, though no single application or site can use more >than a T3 of bandwidth. This is the way that our boxes work (i.e. destination locked onto a single interface). Packet reordering isn't too much of a problem from a functionality perspective for TCP, it just ( ;-) ) affects the performance. It is also atypical for a single site to need more than T3 bandwidth (well, they may want it but they can't really but it yet). >> 3. There seems to be some consensus that we will see an increase in the >> numbers of NAP or MAE like interchange points which could cut down on the >> traffic that must traverse long haul backbones. *BUT* doesn't each >> additional interchange point used by all the top level providers mean >> another new set of global routes crowding router memories? > >It depends. If routing decisions are made locally and the routes heard >at smaller or private exchange points by NSP x are not distributed to >NSP x's larger peering/route-decision routers, then possibly no. That >would mean only hearing routes at private exchange points that were also >heard elsewhere (at a major peering point). Private interconnects (point to point) between the larger backbone providers and new "public" interconnects can be used as appropriate depending on what problem you are trying to solve, and what tradeoffs you are ready to make. >> 4. How much help will regional NAPs like Tucson be? Their goal is to >> keep local traffic local and off long haul backbones. What liklihood is >> there that these will grow in numbers quickly enough to make a >> difference? If the majors start showing up at these points does their >> arrival mean that the problem of crowding memory in their backbone >> routers will be increased? > >See above. > >Avi This depends on a number of factors like how well the local providers are able to aggregate routes, and how the local interconnects link into the rest of the world - for example of the group of local providers gets a large CIDR block to use as a group then they can appear as a single prefix to the rest of the net, while providing portability of numbers for customers that might move between them. dave

1 0

Attempt to summarize Links on the Blink
by Gordon Cook 13 Nov '95

13 Nov '95

I would like to try to understand better where this discussion seems to have come to rest. Yesterday the suggestion was made that the major providers add more bandwidth to their backbones. There seemed to be no assertion as to how this could be done. 1. OC-3 is not yet routable on backbones. Is that correct? 2. What is the routing impact of parrallel T-3s? Or the creation of a mesh of T-3s? I have the impression that this is not feasible because it would expand the routing tables unacceptably or because of the questions of how you would load balance among them?? 3. There seems to be some consensus that we will see an increase in the numbers of NAP or MAE like interchange points which could cut down on the traffic that must traverse long haul backbones. *BUT* doesn't each additional interchange point used by all the top level providers mean another new set of global routes crowding router memories? 4. How much help will regional NAPs like Tucson be? Their goal is to keep local traffic local and off long haul backbones. What liklihood is there that these will grow in numbers quickly enough to make a difference? If the majors start showing up at these points does their arrival mean that the problem of crowding memory in their backbone routers will be increased? 5. How much new network usage is already "in the pipe"? AT&T's outsourcing via BBN - also @home turning CATV into serious net users for example? Does anyone have any idea of growth strains that must be met in the next 6 to 9 months to avoid serious problems like the brick wall that has been mentioned? Certainly bandwidth problems have been cyclical and have been solved before. But someone (Paul Vixie?) suggested that we have a whole series of interlinked problems where pushing on one part of the envelope causes difficulties in another part of the envelope. This sounds pretty serious. Is it? What are the fixes? If technology what are they and how far away? Is the Ncube router what is needed? Wht stands in the way of routing OC-3? Routers? Or ATM? (Someone said that packets should be sent over raw sonet. What stands in the way of doing that? I'd be very interested in further discussion of this in public or private. ******************************************************************** Gordon Cook, Editor & Publisher Subscript.: Individ-ascii $85 The COOK Report on Internet Non Profit. $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook(a)cookreport.com Corporate. Site Lic $650 Newly expanded COOK Report Web Pages http://pobox.com/cook/ ********************************************************************

3 2

Re: Bell vs. Internet Providers (fwd)
by nordlund＠databank.com 13 Nov '95

13 Nov '95

>> no, they have simply identified someone whom they think has no >> alternative to just bleeding more. Ah, the perks of the monarchy. > >the story i heard was not about usage percentage by time, but rather >usage percentage by bandwidth. modems squeeze every possible transition >out of the 3KHz band, while voice calls have few tones and much silence. >this means a modem call takes more bandwidth out of the inter-CO trunks >and LD aggregates. the telco's don't use strict DS0a TDM internally. > >the only reason why usage percentage by time matters to a telco is to >differentiate between the economic impact of G3 FAX vs. V.32bis modems: >they both use all of the link's transitions but FAXes are usually short >lived and so there's nothing to worry about. > >i'm not happy about the trend toward detecting modem users and charging >more for them, but it's an inevitable technical/economic necessity and >that means the PUCs around the united states are all going to have to >let it happen. what's amazed me for the last few years is that it's >taken the telcos so long to realize what they need to do and do it. I observe a lot of users expecting to use ISDN connections as if they were a dedicated line. "ISDN is cheaper than Frame Relay". I have noted that some ISDN tariffs call out higher prices for "data" use of a B channel than analog use. It seems that the phone companies are trying to take advantage of new environments to increase income. On the other hand, it costs a bit more to install ISDN than more analog circuits. I also suspect that long holding times take up ISDN switch capacity. I wonder if telephone engineering is keeping up with the usage changes. Dave Nordlund Dir of Technical Svcs Databank, Inc 913/842-6699 1473 Hwy 40 nordlund(a)databank.com Lawrence, KS 66044 "Your Key to the Internet

1 0