October 1995 - Test - lists.nanog.org

Re: Peering problem with NSP
by patrick＠Verity.COM 31 Oct '95

31 Oct '95

> From: briand(a)fonorola.net (Brian Dickson) > > > > >Now, here is exactly what you ought to desire -- an informed customer. > >Yet, you publically castigate him for asking a mailing list which deals > >with _exactly_ these technical issues. > > My point was, he asked for no detailed technical information from us before > his mail to the nanog list. By being more informed to start with, he will > be better able to ask questions that will get him somewhere. This list Actually he reported that he did ask you for information and his take on the information was that it made no sense, hence he asked us...IMHO that's a reasonable thing to do. To me it looks like your trying to spin the event now, this post has a quite different tone and information than the first you made here. It makes it hard to take you seriously...but it was hard to take the whole thing seriously from the first post...it still makes no sense that you won't guarantee routing for him unless he makes you his primary provider. It sounds like you're just trying to tie him up. > > Absolutely. We are multiply homed, and would recommend it to any large > service provider. Please do not confuse our lack of guarantee for a > discouragement. I don't think that you are effectively...one couldn't count on you unless you were the primary provider. Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

2 1

Re: Peering problem with NSP
by Sean Doran 31 Oct '95

31 Oct '95

Well, when dealing with this off-line, kindly include engineer(a)sprint.net, because quite frankly, *I* have no idea what you're talking about either. Perhaps it's too subtle for me. That kind of information is worth sharing so that both parties' shared customer is satisfied. (And perhaps this will be useful enough for people planning on multihoming between you and other providers than SprtintLink that it should be talked about in a more public forum with a view to helping people understand all the complicated issues involved in multihoming among several transit providing backbones.) Say, I wonder if this'll get me accused of unprofessionalism or disreputableness too? It's been a quiet week; nobody has ranted about me in far too long. Sean. - -- >From list-admin(a)merit.edu Mon Oct 30 20:26:13 1995 X-Sender: briand(a)mail.fonorola.net Mime-Version: 1.0 To: nanog(a)merit.edu From: briand(a)fonorola.net (Brian Dickson) Subject: Re: Peering problem with NSP Cc: Matt Harrop <mharrop(a)interlog.com>, Nathan Stratton <nathan(a)netrail.net>, ericc(a)nds.istar.ca > On Mon, 30 Oct 1995, Matt Harrop wrote: > > > In a few months, the network I operate is going to become > > multi-homed. I've just ordered the T1 from SprintLink and I know that > > they'll have no problem with BGP4 peering, or with the fact that I'll be > > multi-homed. My problem is with my existing NSP; fONOROLA. When I > > informed that that I would be going multi-homed, and asked them about > > peering this was their answer: > > > > > Due to our high level of interconnectivity, we carry over 6k routes >on our > > > backbone. Not all will be available to you. We can only assure you >that direc > > t > > > connect routes will be offered, namely AS2493 & AS812. Transit ASes >cannot be > > > provided to you at this time on a guarenteed basis. If you use us as > > > default, this is not a problem, but I suspect you will not. We have >direct > > > connectivity to CA*net, Rogers, UUNET, WorldLinx, MCI, ANS, and > > > cannot, at this time, ensure that all routes land on you. This kind of > > > routing transit service is not really intended as our usual service > > > offering, and it has a strong impact on our backbone design. > > > > Is this in any way reasonable? fONOROLA's primary connections to the rest > > of the world are MCI and ANS. If they can't provide transit to MCI and > > ANS, they are essentialy useless to me. Of perticular interest to me is > > their last statement. Would this actualy have a "strong impact" on their > > backbone? Matt, I do wish you'd feel free to ask us these sorts of questions directly. We're more than happy to provide you with an explanation, and an honest answer based on the facts will go a lot farther towards providing you with a solution, than open speculation on a mailing list. But feel free to solicit opinions. Language used in networking can be a bit confusing, since some of the aspects of networking are somewhat subtle. I will send you a more detailed explanation, but I wanted to set the record straight in this public forum. The reason we cannot guarantee transit AS connectivity is a direct result of not being your default connection. If you select us as default, we can guarantee transit access. The particulars behind that are technical; I will fill you in off-line, since that information is proprietary. And yes, it really does have a strong impact on our backbone *design*. [ BTW, Matt, we are iSTAR internet, inc. (formerly fONOROLA i*internet). Please use our new name when referring to us, to avoid any confusion. ] > Ya, drop them, they just don't want to do it. > > Nathan Stratton CEO, NetRail, Inc. Your Gateway to >the World! [ Editorial mode on ] Frankly, it is this sort of unenlightened, baseless opinion that gives Usenet its deserved reputation. It certainly doesn't reflect the level of professionalism that a reputable NSP should display, on this list in particular. [ End of editorial mode ] ----------------------------------------------------------------------------- Brian Dickson, Email: briand(a)istar.ca iSTAR internet, inc., Tel : (613) 780-2200 Suite 202, 250 Albert Street, Fax : (613) 780-6666 Ottawa, Ontario, Canada, K1P 6M1 http://www.istar.ca -----------------------------------------------------------------------------

4 3

Re: Peering problem with NSP
by briand＠fonorola.net 31 Oct '95

31 Oct '95

At 10:06 PM 10/30/95, William Allen Simpson wrote: >> From: briand(a)fonorola.net (Brian Dickson) >> I do wish you'd feel free to ask us these sorts of questions directly. >You cut off his excellent rationale, which was (Quoting Matt Harrop): > ># before I start butting heads with their ># management, I want to be sure of the technical issues. > >Now, here is exactly what you ought to desire -- an informed customer. >Yet, you publically castigate him for asking a mailing list which deals >with _exactly_ these technical issues. My point was, he asked for no detailed technical information from us before his mail to the nanog list. By being more informed to start with, he will be better able to ask questions that will get him somewhere. This list is an excellent place to get a second opinion; but for a first opinion it would be best to talk to one's provider(s), due to their intimate knowledge of the particulars. >> Frankly, it is this sort of unenlightened, baseless opinion that gives >> Usenet its deserved reputation. It certainly doesn't reflect the level of >> professionalism that a reputable NSP should display, on this list >> in particular. > >This rather surprises me, since I don't believe that this is a Usenet >distributed list. Actually, that was my point: the comment to which I replied was typical of the news swamp, not of this list. Sorry I wasn't more clear on that. >To conclude, this person states that he is a "service provider". >Providers _should_ be multiply homed. This is encouraged! Absolutely. We are multiply homed, and would recommend it to any large service provider. Please do not confuse our lack of guarantee for a discouragement. ----------------------------------------------------------------------------- Brian Dickson, Email: briand(a)istar.ca iSTAR internet, inc., Tel : (613) 780-2200 Suite 202, 250 Albert Street, Fax : (613) 780-6666 Ottawa, Ontario, Canada, K1P 6M1 http://www.istar.ca -----------------------------------------------------------------------------

1 0

Re: Peering problem with NSP
by William Allen Simpson 30 Oct '95

30 Oct '95

> From: briand(a)fonorola.net (Brian Dickson) > I do wish you'd feel free to ask us these sorts of questions directly. > We're more > than happy to provide you with an explanation, and an honest answer based > on the facts > will go a lot farther towards providing you with a solution, than open > speculation on a > mailing list. You cut off his excellent rationale, which was (Quoting Matt Harrop): # before I start butting heads with their # management, I want to be sure of the technical issues. Now, here is exactly what you ought to desire -- an informed customer. Yet, you publically castigate him for asking a mailing list which deals with _exactly_ these technical issues. > Frankly, it is this sort of unenlightened, baseless opinion that gives > Usenet its deserved reputation. It certainly doesn't reflect the level of > professionalism that a reputable NSP should display, on this list > in particular. This rather surprises me, since I don't believe that this is a Usenet distributed list. My personal reaction was also, "they want you as a captive customer". You say: > ... Transit ASes > cannot be > provided to you at this time on a guarenteed basis. If you use us as > default, this is not a problem.... And: > The reason we cannot > guarantee transit AS connectivity is a direct result of not being your default > connection. If you select us as default, we can guarantee transit access. The > particulars behind that are technical; I surely don't understand what default routing (which would only be outgoing) has to do with your advertisements to other ASs (which would provide him incoming reachability). So, perhaps you can enlighten this technical mailing list? To conclude, this person states that he is a "service provider". Providers _should_ be multiply homed. This is encouraged! Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Re: Peering problem with NSP
by mharrop＠interlog.com 30 Oct '95

30 Oct '95

I would like to extent a public apology to Eric Carroll, Brian Dickson, and the rest of the staff of i*internet. My message ruffled some feathers, and I'm sorry about that. I did not mean to imply that they don't know what they're doing, or are in any way less than competent. On the contrary I have found the i*internet staff to be extremely good at what they do. I would also like to apologize to Eric Carroll for posting an excerpt from his private email, which I did without thinking. BTW: Thanks to all who have replied to my message for your valuable feedback, it's just what I was after. Regards, -- Matt Harrop mharrop(a)interlog.com InterLog Internet Services voice (416) 975-2655 fax (416) 975-9639

1 0

Re: Peering problem with NSP
by briand＠fonorola.net 30 Oct '95

30 Oct '95

> On Mon, 30 Oct 1995, Matt Harrop wrote: > > > In a few months, the network I operate is going to become > > multi-homed. I've just ordered the T1 from SprintLink and I know that > > they'll have no problem with BGP4 peering, or with the fact that I'll be > > multi-homed. My problem is with my existing NSP; fONOROLA. When I > > informed that that I would be going multi-homed, and asked them about > > peering this was their answer: > > > > > Due to our high level of interconnectivity, we carry over 6k routes >on our > > > backbone. Not all will be available to you. We can only assure you >that direc > > t > > > connect routes will be offered, namely AS2493 & AS812. Transit ASes >cannot be > > > provided to you at this time on a guarenteed basis. If you use us as > > > default, this is not a problem, but I suspect you will not. We have >direct > > > connectivity to CA*net, Rogers, UUNET, WorldLinx, MCI, ANS, and > > > cannot, at this time, ensure that all routes land on you. This kind of > > > routing transit service is not really intended as our usual service > > > offering, and it has a strong impact on our backbone design. > > > > Is this in any way reasonable? fONOROLA's primary connections to the rest > > of the world are MCI and ANS. If they can't provide transit to MCI and > > ANS, they are essentialy useless to me. Of perticular interest to me is > > their last statement. Would this actualy have a "strong impact" on their > > backbone? Matt, I do wish you'd feel free to ask us these sorts of questions directly. We're more than happy to provide you with an explanation, and an honest answer based on the facts will go a lot farther towards providing you with a solution, than open speculation on a mailing list. But feel free to solicit opinions. Language used in networking can be a bit confusing, since some of the aspects of networking are somewhat subtle. I will send you a more detailed explanation, but I wanted to set the record straight in this public forum. The reason we cannot guarantee transit AS connectivity is a direct result of not being your default connection. If you select us as default, we can guarantee transit access. The particulars behind that are technical; I will fill you in off-line, since that information is proprietary. And yes, it really does have a strong impact on our backbone *design*. [ BTW, Matt, we are iSTAR internet, inc. (formerly fONOROLA i*internet). Please use our new name when referring to us, to avoid any confusion. ] > Ya, drop them, they just don't want to do it. > > Nathan Stratton CEO, NetRail, Inc. Your Gateway to >the World! [ Editorial mode on ] Frankly, it is this sort of unenlightened, baseless opinion that gives Usenet its deserved reputation. It certainly doesn't reflect the level of professionalism that a reputable NSP should display, on this list in particular. [ End of editorial mode ] ----------------------------------------------------------------------------- Brian Dickson, Email: briand(a)istar.ca iSTAR internet, inc., Tel : (613) 780-2200 Suite 202, 250 Albert Street, Fax : (613) 780-6666 Ottawa, Ontario, Canada, K1P 6M1 http://www.istar.ca -----------------------------------------------------------------------------

1 0

Peering problem with NSP
by mharrop＠interlog.com 30 Oct '95

30 Oct '95

In a few months, the network I operate is going to become multi-homed. I've just ordered the T1 from SprintLink and I know that they'll have no problem with BGP4 peering, or with the fact that I'll be multi-homed. My problem is with my existing NSP; fONOROLA. When I informed that that I would be going multi-homed, and asked them about peering this was their answer: > Due to our high level of interconnectivity, we carry over 6k routes on our > backbone. Not all will be available to you. We can only assure you that direct > connect routes will be offered, namely AS2493 & AS812. Transit ASes cannot be > provided to you at this time on a guarenteed basis. If you use us as > default, this is not a problem, but I suspect you will not. We have direct > connectivity to CA*net, Rogers, UUNET, WorldLinx, MCI, ANS, and > cannot, at this time, ensure that all routes land on you. This kind of > routing transit service is not really intended as our usual service > offering, and it has a strong impact on our backbone design. Is this in any way reasonable? fONOROLA's primary connections to the rest of the world are MCI and ANS. If they can't provide transit to MCI and ANS, they are essentialy useless to me. Of perticular interest to me is their last statement. Would this actualy have a "strong impact" on their backbone? I can't think of any technical reason that they would be taking this position with me. However I'm not a routeing expert, and that's why I'm posting to this list. At this point I'm assuming that their possition is an administrative one, but before I start butting heads with their management, I want to be sure of the technical issues. Thanks in advance, Matt Harrop -- Matt Harrop mharrop(a)interlog.com InterLog Internet Services voice (416) 975-2655 fax (416) 975-9639

2 1

Statistics and network analysis workshop
by hwb＠upeksa.sdsc.edu 30 Oct '95

30 Oct '95

Hi: Lately we have been discussing with the NSF holding a workshop on statistics collection and network analysis. We are thinking about 4/5 January at SDSC in San Diego, but that is still open to changes. We believe we can comfortably accomodate 30 attendees and have an initial (not yet mailed out) invitation list, but are interested in suggestions from NANOG and IEPG relative to attendees and contents and expectations. If we end up with more than 30 people we will likely have to go by who has expressed most interest by means of position papers or so. I will attach a draft of the invitation letter we are planning to mail out. Please email me with your suggestions (no need to litter on the mailing lists). Hans-Werner Dear colleague: The existence of the NSFNET as a "central network" for the research and education community facilitated research into aspects of aggregate network traffic patterns and the anomalies in those patterns caused by the introduction of new or unique applications. Decommissioning the centralized NSFNET backbone resulted in an environment with no dependable public source of statistics on Internet workloads. Gaining insight into the nature of current workloads and their resource requirements, as well as how they change over time, is essential to supporting Internet evolution. For example, the disparity in workload profiles within the current cross section of Internet applications, ranging from high bandwidth-duration multimedia to historically less demanding e-mail or remote login, will necessitate revised metrics for describing aggregate network behavior. Simple mean or peak utilization figures will be dangerously ineffective in addressing a service provider's needs, without also knowing the `transaction' profile constituting and perhaps dominating those figures. (See http://www.nlanr.net/Fix for examples of traffic flow profiling, including data from the FIX-West multiagency network interconnection facility.) The NSF supported Routing Arbiter provides another source of operational statistics collection, via route servers at the NSF supported NAPs. The RA maintains NAP statistics on packet loss and latency among routing peers, BGP routing protocol message counts, route server memory utilization, and selected interface counts on the server. Details and sample statistics on the MAE-East facility are at http://www.ra.net/ra/statistics. To facilitate discussion among communities of academia, equipment vendors, and service providers, who share interest in and incentive to understand one another's views on network statistics and analysis, we will hold a workshop with support of the National Science Foundation. In this workshop we expect to identify, elicit and evaluate the cross sections of interest, goals, willingness, and technical capability to facilitate such studies in the new distributed environment. Critical to the discussions will be the presence of those who can set policy for design and configuration of Internet components: vendors who can design statistics collection mechanisms, and service providers who can ensure the effective employment of those mechanisms to support their short and medium term engineering requirements to deliver and maintain a stable on a daily basis. Also critical is a user representation, on who's behalf the network is built. If you would like to participate, it would help us greatly to obtain from you a short position statement in advance. ou will have an opportunity to discuss these views during the workshop. Please also let us know whether you are interested in giving a short presentation of your views to the workshop attendees. From the workshop we will construct a report to be distributed to the participants, the National Science Foundation, and other interested parties. We will also attempt to make position statements and pointers to relevant information available via the Web in advance, as we receive them, to allow for information distribution prior to the workshop. The workshop will be held in January 1996 at the San Diego Supercomputer Center. Attached you will find attendance information. Please confirm with us by responding to this note whether you expect to attend. We have submitted a proposal to the National Science Foundation to help those participants who do not have own funding to cover the travel for the workshop. If this is the case for you, please contact us for information about possible availability of such funds. Hans-Werner Braun, and Kimberly C. Claffy (SDSC), and Mark W. Garrett (Bellcore) Workshop co-chairs

1 0

New mailing list announcement
by Eric Kozowski 30 Oct '95

30 Oct '95

A new mailing for discussing Internet related activities, ISP's, etc. in the Pacific NW has been established. To join this list, send email to: majordomo(a)structured.net and put "subscribe nw-internet" in the message _body_ (not the Subject: line) -- Eric Kozowski Structured Network Systems, Inc. kozowski(a)structured.net Better, Cheaper, Faster -- pick any two. (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS1

2 1

Re: hum. Is the net-39 experiment expanded to net-38?
by Sean Doran 30 Oct '95

30 Oct '95

Gack. Fix, PSI, you are killing the Internet, and we may have to disconnect from you. Sean.

1 0