- Test - lists.nanog.org

Re: usable T1 bandwidth
by Alex Rubenstein 18 Mar '97

18 Mar '97

1536 kb/s (24 x 64 kb/s). But, protocol (PPP and IP) overhead can eat a lot of that, 10-20%) At 12:46 PM 3/18/97 -0500, Steve Crumley wrote: >How much of the 1.544 Mbits/second of a T1 are available to IP? I know >some bits are taken for framing and such. I think I remember it is >around 1.3 something. >Thanks, >-Steve >

1 0

Re: NANOG 10
by John R. Sosebee 18 Mar '97

18 Mar '97

At 01:59 PM 3/18/97 -0500, Pam Ciesla wrote: > >Will be held in Tampa, Florida June 5th & 6th. All info is available via Is this just coincidence that cisco Networkers '97 is June 3-5 in Orlando. little over an hour from Tampa ? -Paul F. ... can you say "a week at the beach ? " >http://www.nanog.org/. Networking tutorial is scheduled 7:00-9:00PM >Wednesday evening (subject TBA). Please note payment information on the >registration page before registering. Any questions contact me at >(313)936-0172 or e-mail. Thanks > Pam Ciesla > John sosebee(a)bellsouth.net (770) 392-4300

1 0

NANOG 10
by Pam Ciesla 18 Mar '97

18 Mar '97

Will be held in Tampa, Florida June 5th & 6th. All info is available via http://www.nanog.org/. Networking tutorial is scheduled 7:00-9:00PM Wednesday evening (subject TBA). Please note payment information on the registration page before registering. Any questions contact me at (313)936-0172 or e-mail. Thanks Pam Ciesla

1 0

Re: FYI: BBN/MCI Peering Change 3/31/97
by Dave Curado 18 Mar '97

18 Mar '97

>>> The technical impact of this change is that MCI will no longer announce >>> BBN routes at the public interconnects, except to those providers who >>> have purchased transit service from MCI. >> You're inferring I can buy transit from MCI at the naps. >> If that is true, please let me know. I meant implying -- please, no more corrections needed. =-) > Not at all. The only inference you can draw is that MCI does > indeed sell transit services, and that as part of that service, > they will announce BBN routes to you. Indeed, they will announce > everyone's routes to you if you so desire as a transit customer. > No claims, or even vague references are made as to how or where > that transit service connection is made. Um, yes, I think there was at least a vague reference in there. =-) (read it again) My intention, by the way, is not to simply pick nits over a posting. I have heard in the past that there is at least one major provider who sells transit through the naps. Regardless of whether that is an OK thing to do or not, I am sincerely interested in knowing if that is true. > I know MCI will be quite willing to provide you transit services > over a DS3 you purchase from them. Of course, there's the matter of the > small additional fee for transit services. :-) You're implying they won't sell me transit over a T1? (just kidding) davec

1 0

Re: FYI: BBN/MCI Peering Change 3/31/97
by Dave Curado 18 Mar '97

18 Mar '97

> The technical impact of this change is that MCI will no longer announce > BBN routes at the public interconnects, except to those providers who > have purchased transit service from MCI. You're inferring I can buy transit from MCI at the naps. If that is true, please let me know. davec

3 2

request for data
by Scott Yoneyama 17 Mar '97

17 Mar '97

Does anyone know some sources I can go to for data on bandwidth needs, technological marketplace, and other telecommunications information (i.e. number of major corporations, carriers, etc.) for the Bay Area and Los Angeles? I trying to justify some network expansion and need to focus the data on not only those marketplaces, but be able to pull enough specific data to show the effect on the northwest. All suggestions are desparately appreciated! Scott Yoneyama Director Starcom Service Corporation 206-448-4034 206-448-4485 fax yone(a)wolfenet.com

1 0

FYI: BBN/MCI Peering Change 3/31/97
by L. Sean Kennedy 17 Mar '97

17 Mar '97

Just over two years ago BBN/NEARNET, BBN/BARRNet, and SURAnet (later BBN/SURAnet) independently selected MCI to provide Network Service Provider (NSP) transit services. The transit agreement obligated BBN-owned regionals to use MCI for transit services. Over the past two years BBN has migrated from this collection of semi-autonomous regional networks to one nationwide infrastructure. We have made minimal use of MCI transit services, using existing connections to MCI primarily to reach MCI customers. In light of this change and in order to provide improved connectivity to their customers, BBN and MCI have agreed to replace the transit service agreement with a private peering agreement. Cessation of the transit agreement is scheduled for 3/31/97. The technical impact of this change is that MCI will no longer announce BBN routes at the public interconnects, except to those providers who have purchased transit service from MCI. Providers with significant trans-national US infrastructure at DS3 or greater speeds who are reliant on MCI's announcement of AS1 prefixes are encouraged to pursue peering with BBN by contacting 'peering(a)bbnplanet.com' by 3/19/97. Those providers with a existing transit provider who peers with BBN should see no change in how they reach BBN customers (and should contact their transit provider with questions regarding its connectivity). Existing peers of BBN will see no change in our announcements or routing. Sean

1 0

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

17 Mar '97

[BGP Metrics] Tony Li wrote: >First, any such proposal should have a reasonable architecture. Not just a >description of the mechanism. Motivational explanations are most welcome, >preferably sprinkled with real world examples. Agreed, though i was coming to it from the diffrent angle -- out of the sense of general disgust about having several different metrics, every one being rather limited. I.e. the idea was to introduce a simple generic mechanism including all existing metrics as particluar cases. >Second, there's the issue of the consistency of the values used. As I >recall your proposal, each domain in the path would propose a metric for >its contribution for a prefix. A receiving domain then weighted each >domain in whichever way it chose to arrive at a final, composite metric. >Thus, the semantics of the metric are hardly clear. There's a clear statement that the default value of a single AS hop is 1.0. Since there's no central administration, there's no way to coordinate the scale of metrics globally (i.e. what constitutes 1/2 of a default hop?) -- so the weights are provided to give other parties ability to compensate the variations in the interpretation. The reason for carrying a vector is to make possible establishing local policies on values originated from remote side, and to allow operators to do things like having closer metrics to have higher costs (i.e. the more remote as-path component is, the less important its metric is). >Third, there's the pragmatic issue of implementation cost. Yes, the cost >of an integer per AS in an AS path is tolerable, tho not "cheap". This >cost becomes painful if most domains are not using the metric. Then it does not take space in the path attributers. I.e. if you have a box implementing proposed metrics, and use only old-style paths, you end up with identical updates and identical results of their comparison. If old boxes implement transitive attributes properly, their effect would simply be setting static metric 1.0 for a hop. >And it becomes more painful if two prefixes with otherwise identical attributes >have different metrics. This results in them not landing in the same >update, thereby increasing overhead. Are we willing to take a signficant >step forward in overhead for this flexibility? Exactly the same happens when you have different MEDs or different communities. Since the proposal obsoletes MEDs and LOCAL_PREFs (and makes the practice of ASN replication unnecessary) the overall overhead is likely to be close to zero (providing that same policies are implemented). --vadim

1 0

Re: GRIDNET wake up
by Michael Reed 17 Mar '97

17 Mar '97

The whois contact has move to a better company (me) the remaining engineers probable do no know who is being probed you can contact them at twilkens(a)gridnet.com lprovow(a)gridnet.com ---------- > From: Randy Bush <randy(a)verio.net> > To: nanog(a)merit.edu > Subject: GRIDNET wake up > Date: Sunday, March 16, 1997 7:00 AM > > 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

2 1

Re: consistent policy != consistent announcements
by garyz＠savvis.com 17 Mar '97

17 Mar '97

I agree. the BGP path is a blunt instrument. BGP is in need of real metrics. I really want to fine tune but find it hard with current abilities of BGP. I would also like to use the bits within the TCP/IP header to help determine class of services which is there but no one uses or seems to care about. We could offer some really good services to the internet if we could get this fine-grained control. But, when you get down to it, most companies are having a hard time with this from a resource and the overhead cost on routers. I think the big companies (cisco) are holding us back. We need routing to take place more on a switch fabric, hardware/card based, vrs software based routing. Routers like the Ascend (NetStar) are a step in the right direction. This will help take care of the third issue. Gary Zimmerman V.P. of Network Engineering Savvis Communications "I don't wear the uniform to play, I wear it to win!" Larry Byrd ---------- > From: Tony Li <tli(a)jnx.com> > To: Vadim Antonov <avg(a)pluris.com> > Cc: nanog(a)merit.edu > Subject: Re: consistent policy != consistent announcements > Date: Sunday, March 16, 1997 10:58 PM > > > 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? > > Well, for several reasons. > > First, any such proposal should have a reasonable architecture. Not just a > description of the mechanism. Motivational explanations are most welcome, > preferably sprinkled with real world examples. > > Second, there's the issue of the consistency of the values used. As I > recall your proposal, each domain in the path would propose a metric for > its contribution for a prefix. A receiving domain then weighted each > domain in whichever way it chose to arrive at a final, composite metric. > Thus, the semantics of the metric are hardly clear. > > Third, there's the pragmatic issue of implementation cost. Yes, the cost > of an integer per AS in an AS path is tolerable, tho not "cheap". This > cost becomes painful if most domains are not using the metric. And it > becomes more painful if two prefixes with otherwise identical attributes > have different metrics. This results in them not landing in the same > update, thereby increasing overhead. Are we willing to take a signficant > step forward in overhead for this flexibility? > > Tony

1 0