- Test - lists.nanog.org

RE: connectivity outside the US
by Barry Raveendran Greene 01 Jun '97

01 Jun '97

Hello Chris, > Worldcom and Cable & Wireless are in the process of laying a 20 Gbps > transatlantic sonet (DWDM) system which they claim doubles the current > transatlantic capacity. The southern route should be done by November > of this year with the first capacity available for the end of the year. > The northern route, which will close the ring, will be done in '98. Only 20 Gbps? KDD is putting a 100 Gbps around Japan. Due in 1998. ;-). Barry -- -- -- Barry Raveendran Greene | || || | Senior Consultant | || || | Consulting Engineering | |||| |||| | tel: +65 738-5535 ext 235 | ..:||||||:..:||||||:.. | e-mail: bgreene(a)cisco.com | c i s c o S y s t e m s |

1 0

RE: connectivity outside the US
by Barry Raveendran Greene 01 Jun '97

01 Jun '97

Hello Jesse, > Undersea capacity is expensive for 3 reasons: > 1) It's under the ocean > 2) It's under the ocean > 3) It's under the ocean Actually, based on first hand experience, the cost of installing a oceanic cable is _not_ the driving factor that makes oceanic bandwidth so expensive. The key factors involve the relationship between the partners of any one of the cable consortiums. Each of the partners are telcos. Telcos who compete with each other in the region do not have each other's interest at heart. Hence, when they set the prices for the cable capacity, the prices get jacked up. When ever one telco mis-forecasts and runs out of capacity on a cable, the other "partners" jack up their prices even further and sell it to the unfortunate "partner" who ran out of capacity. These pricing games between the telcos over oceanic bandwidth is one of the key factors for the high cost end customers experience. The problem with all of this is there is little information available that explains how oceanic bandwidth politics. This is why we've got a couple of blocked out sessions during APRICOT that covers oceanic and space segment (satellite) technology and politics. IMHO - Education is the best weapon to lowering the cost of oceanic bandwidth. Barry -- -- -- Barry Raveendran Greene | || || | Senior Consultant | || || | Consulting Engineering | |||| |||| | tel: +65 738-5535 ext 235 | ..:||||||:..:||||||:.. | e-mail: bgreene(a)cisco.com | c i s c o S y s t e m s |

1 0

RE: connectivity outside the US
by Barry Raveendran Greene 01 Jun '97

01 Jun '97

Hello Miguel, > Yes, the demand far outstrips the supply of bandwidth, we > are having that problem right now. Never mind that the we > can afford the > $60,000/month for a measly T1 to the US - > we are currently back-ordered as there is not enough available > channels across the Pacific. Actually, there is plenty of bandwidth coming out of the Philippines. The problem is that the telco you are working with did not do their bandwidth forecast correctly. Hence, they did not buy the enough allocations from the cable consortiums. This is why you are waiting. Your telco is waiting until the next cable consortium bidding cycle (June) to get more bandwidth allocated so they can sell it to you. The telco could get you your T1 now, but they would have to buy the capacity "out of cycle." This is expensive since they either have to buy the bandwidth off one of the other telcos in the region or at "out of cycle" rates from the cable consortium - both are very expensive. [lots deleted] > > or start coming to the same understanding: access to trans-oceanic > > capacity while it continues to be hiddeously expensive should be > > paid for at both ends, since both sides benefit. > > How do we come up with a settlement model? First you need the tools to measure flows. They did not exist several years ago. Today, with the work in RTFM (Real Time Flow Metering WG in IETF), Caida, Netflow, and other tools, the technical foundation required to create settlement agreements similar to the ones in the voice world are now possible. -- -- -- Barry Raveendran Greene | || || | Senior Consultant | || || | Consulting Engineering | |||| |||| | tel: +65 738-5535 ext 235 | ..:||||||:..:||||||:.. | e-mail: bgreene(a)cisco.com | c i s c o S y s t e m s |

1 0

RFC 1918 addresses
by Paul A Vixie 31 May '97

31 May '97

I think that any exposure of these addresses outside their addressing realm is a mistake. Using them for otherwise unnumbered serial links would be fine if Cisco had an option to "use loopback address when sending ICMP's" but they don't. Traceroute is sending increasing-TTL'd UDP datagrams, and if you are seeing a 10.0.0.2 source address on an router's ICMP to you it means you would get that as a normal ICMP too -- meaning not just one due to a diagnostic like Traceroute. I think this is an error. Exposing an RFC 1918 private address in, say, a "Received:" header in e-mail is less of a problem, though the spammers who do it are actually better able to cover their origins, there's no way to prevent it and no normal damage from doing it. No IP datagram with an RFC 1918 address in the protocol headers should be allowed outside a private addressing realm. This means not the source address, not the destination address, and not the encapsulated addresses inside an ICMP payload.

1 0

Re: connectivity outside the US
by Daniel McRobb 31 May '97

31 May '97

> smd(a)clock.org (Sean M. Doran) wrote: > > > Examining this a bit more closely, since undersea capacity is > > terribly expensive, when there is adequate capacity available > > to a large aggregate of sites people want to get to, there will > > be an obvious market for access to that capacity. > > Actually, i do not understand why undersea capacity is so > expensive. Cable is more expensive, yes; but the paths > are much straighter, and there's no need to purchase > rights of ways (except for shore-side strips). There's > no need to dig trenches -- you just drop the cable off the > boat. >From what I've read, it's quite difficult to lay undersea cable. There was a nice article in the Dec. 1996 issue of WIRED covering the FLAG (Fiberoptic Link Around the Globe) project, written by (of all people) Neal Stephenson. Online at: http://wwww.wired.com/wired/4.12/features/ffglass.html Daniel ~~~~~~

1 0

Re: 10.0.0
by Danny McPherson 31 May '97

31 May '97

> You can have an internal mesh made up of entireley rfc1918 address > space, and not leak these routes to the rest of the world, I've only > once caught MCI leaking stuff from a test lab, which was kinda annoying, > but not really anything bad, and a polite e-mail message to them got > an immediate fix of the problem. > i'd think most providers filter rfc1918 addresses both inbound and outbound at naps (mci does, i believe), although maybe not to customers... using reserved address space internally (as long is it remains internal), seems like a good idea to me - isn't that why it was reserved? -danny

2 1

Re: 10.0.0
by Tony Li 31 May '97

31 May '97

doshea(a)mail.wiltel.net (Dave O'Shea) writes: > >> The only services that should be affected by the use of such "bogus" > >> addresses will be traceroute and any routing information passed by the > >> device. > > > >Unfortunately that's not quite true. > > > >There are a variety of services which rely on messages received from > >intermediate hops that would break if the the sending host happened > >to filter out RFC1918 addresses and a part of the network > >were using them. > > > >Probably the best example is Path MTU Discovery. > > I meant "services used by normal humans in the course of downloading nude > .gif's", i.e., typical Internet customers. I stand by my statement. :-) As the "normal human in the course of downloading nude .gif's" should be using Path MTU Discovery, I think you're agreeing.... Tony p.s. .gif's are obsolete. Most everything is .jpg's, .mpg's, and .avi now. ;-)

1 0

NANOG Mailing List
by William B. Norton 31 May '97

31 May '97

Hello - I would like to ask that we all take a deep breath and refrain from the attacks, retaliations from attacks, and the subsequent comments on the attacks. This will not likely lead to anything good. It seems to me that we have an issue about the appropriate use of the NANOG mailing list forum. I would like to suggest that during the open session Friday afternoon we spawn a small group to draft a nanog mailing list AUP, and perhaps draft a charter for a couple of new nanog-XXX lists. We can then post the document to the nanog list(s) and implement the policy. Bill -------------------------------------------------------------- William B. Norton <wbn(a)merit.edu> (313) 764-9430

2 1

Re: 10.0.0
by Dave O'Shea 31 May '97

31 May '97

>> The only services that should be affected by the use of such "bogus" >> addresses will be traceroute and any routing information passed by the >> device. > >Unfortunately that's not quite true. > >There are a variety of services which rely on messages received from >intermediate hops that would break if the the sending host happened >to filter out RFC1918 addresses and a part of the network >were using them. > >Probably the best example is Path MTU Discovery. I meant "services used by normal humans in the course of downloading nude .gif's", i.e., typical Internet customers. I stand by my statement. :-)

1 0

Re: 10.0.0
by Dave O'Shea 31 May '97

31 May '97

I've noted several providers, including a couple of better-known ones, using RFC1597 addresses internally. While not a Really Optimal Solution, it does work, and if you find yourself with only a couple of class C's to work with.. I'd probably rather preserve them for my customers, and go with whatever I had to internally, as long as packets still got from A to B. The only services that should be affected by the use of such "bogus" addresses will be traceroute and any routing information passed by the device. Much more interesting is when you have to connect to several different customers, many of whom have chosen 10/8, 172.16/16, or 192.168.1/24 as their core network addresses. Looks like Sierra is a customer of Phoenix Fiberlink, who is likely dual-homed, since he's got a Sprint netblock transiting UUnet. Hope that helps. ---------- > From: Janet Pippin <jdp(a)cyberramp.net> > To: nanog(a)merit.edu > Cc: Larry Rosenman-CyberRamp System Administration <ler(a)cyberramp.net> > Subject: 10.0.0 > Date: Friday, May 30, 1997 10:53 PM > > ALL: > Upon trying to discover an abuse site's network location, I > happened upon this: > > Now, first it goes to sierra.. Then right after the trace finishes, > I ran the second one.. > > traceroute to ns1.sierra.net (207.135.224.247), 30 hops max, 40 byte packets > 1 cisco.cyberramp.net (207.158.64.1) 2 ms 1 ms 1 ms > 2 166.48.80.9 (166.48.80.9) 6 ms 8 ms 13 ms > 3 core3.Dallas.mci.net (204.70.4.13) 5 ms 7 ms 16 ms > 4 uunet-hssi.Dallas.mci.net (206.157.77.130) 26 ms 7 ms 56 ms > 5 Fddi0-0.CR1.DFW1.Alter.Net (137.39.37.35) 103 ms 13 ms 15 ms > 6 108.Hssi5-0.CR1.SFO1.Alter.Net (137.39.70.221) 135 ms 312 ms 348 ms > 7 133.Hssi4-0.GW1.SLT1.Alter.Net (137.39.68.10) 104 ms 121 ms 122 ms > 8 pfi-gw.customer.ALTER.NET (137.39.167.18) 108 ms 171 ms 106 ms > 9 207.49.13.50 (207.49.13.50) 114 ms 117 ms 112 ms > 10 207.14.235.22 (207.14.235.22) 112 ms 116 ms 113 ms > 11 10.0.0.2 (10.0.0.2) 116 ms 108 ms 114 ms > 12 rock.sierra.net (207.135.224.247) 116 ms 112 ms 113 ms > > jdp@mailhost 18 ~ > wi 10.0.0 > IANA (RESERVED-6) > > Netname: RESERVED-10 > Netnumber: 10.0.0.0 > > hrmm... and the second one: > > jdp@mailhost 17 ~ > t ns1.sierra.net > traceroute to ns1.sierra.net (198.60.22.2), 30 hops max, 40 byte packets > 1 cisco.cyberramp.net (207.158.64.1) 2 ms 1 ms 1 ms > 2 166.48.80.9 (166.48.80.9) 29 ms * 5 ms > 3 bordercore1-loopback.Denver.mci.net (166.48.92.1) 210 ms 252 ms 281 ms > 4 electric-light.Denver.mci.net (166.48.93.254) 274 ms 273 ms 260 ms > 5 F0-0.slkcib01.eli.net (207.0.56.18) 59 ms 59 ms 62 ms > 6 XMISSION-DOM.slkcib01.eli.net (207.49.20.86) 64 ms 67 ms 69 ms > 7 xmission.xmission.com (198.60.22.2) 60 ms * 88 ms > jdp@mailhost 18 ~ > > > enlighten me, someone... :( > > -janet > > > Janet Pippin * CyberRamp Internet Services > Network Administrator *** 11350 Hillguard Road > jdp(a)cyberramp.net * Dallas, Texas 75243-8311 > http://www.cyberramp.net * (214) 340-2020 (817) 226-2020

4 3