June 2001 - Test - lists.nanog.org

Re: Why so little traffic from C&W
by Sean Donelan 10 Jun '01

10 Jun '01

On Sun, 10 June 2001, Sean M. Doran wrote: > Rachel Warren <rachel(a)telco-bitch.com> quotes Bill Manning and replies: > | > There was never any governmental sanction of the term or > | > concept of tier anything associate with the NSFnet or its > | > transition. > | > | And this is definately a good thing. > > It's also not true. NSF 93-52 did indeed specify > precisely what type of backbone the funded regionals could > connect to, and it required those distinguished backbones > to interconnect in specific locations (the "priority" NAPs). > > The name "tier" wasn't used wrt eligible and ineligible > backbones, but there was an explicit ranking of preference by the > NSF that was based on specific interconnectivity, and that mapped > very cleanly onto the then tier-1 backbones, with the exception of > UUNET, which didn't play (and MFS's NAP wasn't even a "priority" one). The NSF only specified connectivity to the NAP, not interconnectivity between providers. Due to problems with various NAPs, who connected to what was always in flux. For example, the Chicago NAP was designated a "priority NAP." But networks service providers (NSPs) were very slow to connect to chicago. I believe ANS went through various periods of not connecting, connecting, and disconnecting at the Chicago NAP. MCI's connection to the chicago NAP didn't work for months at a time. Well, the MCI vBNS connection worked, but the InternetMCI connection didn't. There were some networks which didn't connect to either of the ATM NAPs (Chicago and San Francisco) because their engineers didn't like ATM. They only used the Gigaswitch based NAPs. UUNET and Genuity are examples of networks which declined to connect to the ATM networks for a long, long time. If I recall my history, PSI and AGIS were the first two networks to connect to all the priority and non-priority NAPs of the day (Chicago, New York, San Francisco, MAE-East and the de facto CIX router). A Sprint engineer was one of the most vocal opponents to the ATM naps.

1 0

Re: Why so little traffic from C&W
by smd＠clock.org 10 Jun '01

10 Jun '01

Rachel Warren <rachel(a)telco-bitch.com> quotes Bill Manning and replies: | > There was never any governmental sanction of the term or | > concept of tier anything associate with the NSFnet or its | > transition. | | And this is definately a good thing. It's also not true. NSF 93-52 did indeed specify precisely what type of backbone the funded regionals could connect to, and it required those distinguished backbones to interconnect in specific locations (the "priority" NAPs). The name "tier" wasn't used wrt eligible and ineligible backbones, but there was an explicit ranking of preference by the NSF that was based on specific interconnectivity, and that mapped very cleanly onto the then tier-1 backbones, with the exception of UUNET, which didn't play (and MFS's NAP wasn't even a "priority" one). | I don't think I would want to see my tax money being used by the | Department of Standards to define "Tier-1". Been there, done that, got the bruises (thanks pford & priscilla, I like the "I went to Danvers and all I got was a meeting behind my back" t-shirt souvenir). Sean.

1 0

RE: /24s run amuck again
by Dave Israel 10 Jun '01

10 Jun '01

[Rant below. My apologies. Sometimes, your spleen needs a-ventin'.] I know I'm behind on this conversation, but I want to say that, for the record, Bellovin's presentation, and the resultant "You're not paying me for my routing table, you bastard" sentiment, drives me up a wall. BGP is for setting and sharing policy. If you don't want to listen to somebody else's legitimate policy, the right answer is not to filter that policy; the right answer is not to peer. If you're not interested in policy decisions, you can get static routes by examining the routing arbiters or even the registries' records. Despite what some venders want you to believe, memory is cheap, processors that can handle the Internet routing table are cheap, and the only really expensive things to build in a router are the high speed line cards and the forwarding engine(s) to push them. If we were running the Internet on 68020 processors over 56k and T1 lines still, you would have a point. But the additional load of allowing other people to set their policy as they see fit is not a relevant concern on modern equipment. There are lots of legitimate reasons for making announcements like this. One is backup connectivity; if the primary fails, and you're filtering the backup, you might not be taking the best path to the end user. In fact, if you're well connected, you're passing it off to the primary, who, if he is filtering as well, won't pass it off to the secondary, and if he's not filtering, you're transiting when you don't need to. At a bare minimum, you're putting the decision off to your provider, in which case, why are you peering in the first place? Another is load sharing; if I have 60MB of traffic for my site, and I have two T3s, I might set policy to try to equalize that data. If you ignore my policy, you might overload one of the links and not be able to reach my site. I suffer, your customers suffer, eveybody gets pissy, because you didn't have 2k of RAM to share with a fellow member of the Internet whose down on his luck. You should do this to be a good neighbor. You should do this to be charatable. You should do this because you might need it yourself someday. Now, before anybody gets the wrong idea, yes, I know there are people who announce their supernets as /24s or smaller because of technical incompetance. The ISPs should do what they can to prevent that; I know that we have historically been rat bastards to our customers who wanted to make smaller announcements and couldn't tell us why. And there are people who are running old hardware, or are being victimized by 800% markup by the vendor, or otherwise really cannot spare the cycles and the RAM to support other people's policy. You gotta do what you gotta do. But hogging cycles you aren't using, and memory that is sitting idle, on some sort of "You're not paying me" principle, is just absurd. -Dave On 6/9/2001 at 13:47:15 -0700, Randy Bush said: > > >>> There are lots of reasons to have some diverse /22 announcements in your > >>> network for example. > >> but if you are not paying me, what reasons are there for me to spend > >> my resources (route bloat) so you can engineer your traffic? > > The fact that your other customers are paying you to reach everyone on the > > internet? > > red herring alert! the point is not reachability. the aggregate is still > available. see bellovin's phoenix presentation. > > randy -- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet

1 0

Re: Multicast Traffic on Backbones
by Sean Donelan 10 Jun '01

10 Jun '01

On Sun, 10 June 2001, Joshua Goodall wrote: > > I have found that most sales reps don't know what multicast is, or why it > > is important to have. > > many network engineers glaze over at the mention of multicast. it > takes some serious grey matter work to fathom the entire subject. Essentially every major network operator has one network engineer who can set up multicast for customers. The problem is very few networks have figured out how to turn multicast into a commercial product. So if you don't find that one engineer, you are out of luck. Unicast streaming may be less efficient, but most providers can figure out how to charge for it and make it a supported product. Unfortunately some folks have confused multimedia with multicast. While I've seen many multimedia multicast applications, I haven't seen one which can't have its essential elements replicated by unicast streams. Is there a killer-ap for multicast?

3 2

RE: /24s run amuck again
by Philip Smith 10 Jun '01

10 Jun '01

Hi Richard, I was working on almost the same thing... :-) As from next Friday, my routing report will include the top 20 ASes which are announcing prefixes more specific than the registry minimum allocation (/20), more specific than a /24 from 192/8 space, more specific than a /16 from former B space, more specific than a /8 from former A space... A taster follows: Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Description 701 1584 UUNET Technologies, Inc. 1221 1580 Telstra 705 1490 UUNET Technologies, Inc. 2764 866 connect.com.au pty ltd 3491 651 CAIS Internet 7046 623 UUNET Technologies, Inc. 690 502 Merit Network 4293 481 Cable & Wireless USA 18994 468 Global Crossing 7018 437 AT&T 15870 436 Global Center Frankfurt 1 429 BBN Planet 702 423 UUNET Technologies, Inc. 1239 364 Sprint ICM-Inria 209 350 Qwest 5106 343 Ameritech Advanced Data Servi 3561 332 Cable & Wireless USA 18993 325 Global Crossing 11371 307 Rhythms NetConnections 4323 303 Time Warner Communications, I There is no attempt to measure aggregation - that's the job of the CIDR Report. This simply looks at the prefix announced and if it is outside the above limits, it is counted. Makes very interesting reading... philip -- At 13:53 08/06/2001 -0400, Richard A. Steenbergen wrote: >On Fri, Jun 08, 2001 at 09:31:03AM -0700, Karyn Ulriksen wrote: > > > > I had a full /19 sliced and diced up into /24 until yesterday when I > > officially completed my data center migration. None appear in the list > > below. How recent is this information? > >Woops, I was running this against an old routing table. My appologies. > >I've updated the list to reflect a routing table taken this morning from >1720 (CERF) and 3967 (Exodus) transit. I'm still debugging the parser, so >it may not be 100% perfect, but the point remains the same. > >The url is the same: >http://www.e-gerbil.net/ras/projects/ipaddr/24amuck.txt > >-- >Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras >PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

8 17

RE: Multicast Traffic on Backbones
by Michael Whisenant 10 Jun '01

10 Jun '01

Most multicast backbone providers have links that show that they mBGP with peers and offer MSDP as well. This allows for the customer on one providers network to access a source on another providers network. Of course there are issues with the 5 bit overlap in multicast address space, but it does work. There are commercial companies that have registered/reserved particular addresses for their applications as well. While I think that today the amount of multicast traffic is low, it will continue to increase. On Sat, 9 Jun 2001, Deepak Jain wrote: > > When multicast enabling a network, am I wrong in assuming that the routers > will only multicast to their direct, end-user connections and peers (like an > access router will only offer streams to its direct connections)? I am > trying to figure out what advantages multicast-enabling a backbone has when > the majority of customers are not multicast-peers of their upstream routers. >

1 0

PSI, NetZero contact?
by Charles Scott 10 Jun '01

10 Jun '01

Can anyone point me to PSI and NetZero contacts that can follow up on a customer abuse problem? I've been reporting abuse from this guy (Yukio - anyone else been dealing with this nut case?) time and time again and despite getting numerous notices back from PSI that they are "...taking the necessary steps...", they have yet to solve the problem. NetZero also doesn't seem to be doing anything on this. Chuck Scott Gaslight Media cscott(a)gaslightmedia.com

1 0

router failutes inside PacBell
by alex＠yuriev.com 10 Jun '01

10 Jun '01

Anyone knows any details? Alex

1 0

Re: /24s run amuck again
by Steven M. Bellovin 09 Jun '01

09 Jun '01

In message <5.1.0.14.2.20010609145116.021b5d00@popcorn>, John Starta writes: > >The link on the NANOG web site points to the wrong presentation. Perhaps >you would be so kind as to forward me a copy? http://www.research.att.com/~jrex/nanog/lost.html --Steve Bellovin, http://www.research.att.com/~smb

1 0

POS OC48 interfaces using different wave length
by Vincent Gillet 09 Jun '01

09 Jun '01

Hello all, I am thinking about using different POS interfaces on dark-fibers. On one side, i already have POS-OC48-LR card (Cisco). This card use 1550 nm wave length. We would like to use a POS-OC48-SR (Cisco). This card use 1310 nm wave length. Are 1310 and 1550 optics comptatible ? If yes, i guess that there is impact on the power Budget available. How-Much ?! Some colleagues reported successful implementation with such config (Cisco POS OC48 Cards) It looks strange to me and i wonder if Juniper and Cisco POS OC48 would also work corretly in such environnement ... I guess that "official" answer from manufacturer would be : NO WAY :-) Some carriers may already tested such config ? Any feedback ? Thanks. V

10 10