- NANOG - lists.nanog.org

Re: BGP/Multihoming
by Howard C. Berkowitz 09 Nov '97

09 Nov '97

url not found http://ds.internic.net/internet/drafts/draft-berkowitz-multirqmt-00.txt OOPS! That should be, http://ds.internic.net/internet-drafts/draft-berkowitz-multirqmt-00.txt On Sat, 8 Nov 1997, Howard C. Berkowitz wrote: > I've posted an Internet Draft intended to help clarify some confusing > alternatives that CID students often ask. Discussions on the NANOG mailing > list, as well as my student questions, suggested to me there might be a > need for a tutorial at a different level of abstraction than the specific > technique discussions that are available. > > It's not intended to show how, for example, to do BGP multihoming. It's > intended to help someone, especially an end user organization, decide what > the problem is they are trying to solve. Once they know that, the next > step will be selecting DNS-based methods, and/or routing-based methods > using BGP or IGPs. Comments very welcome, especially in the DNS area. > > My plan is to submit this to the IDR WG at the IETF in December, but it's > an individual contribution at this point. > > > To Be Multihomed: Requirements & Definitions > draft-berkowitz-multirqmt-00.txt > > You can FTP or HTTP it from: > > ds.internic.net/internet/drafts/draft-berkowitz-multirqmt-00.txt > > > 2. Abstract > > As organizations find their Internet connectivity increasingly critical > to their mission, they seek ways of making that connectivity more > robust. The term ''multi-homing'' often is used to describe means of > fault-tolerant connection. Unfortunately, this term covers a variety of > mechanisms, including naming/directory services, routing, and physical > connectivity. This memorandum presents a systematic way to define the > requirement for resilience, and a taxonomy for describing mechanisms to > achieve it. Multiple mechanisms may be appropriate for specific > situations, including DNS, BGP, etc. > > >

1 0

Re: BGP/Multihoming
by Howard C. Berkowitz 08 Nov '97

08 Nov '97

I've posted an Internet Draft intended to help clarify some confusing alternatives that CID students often ask. Discussions on the NANOG mailing list, as well as my student questions, suggested to me there might be a need for a tutorial at a different level of abstraction than the specific technique discussions that are available. It's not intended to show how, for example, to do BGP multihoming. It's intended to help someone, especially an end user organization, decide what the problem is they are trying to solve. Once they know that, the next step will be selecting DNS-based methods, and/or routing-based methods using BGP or IGPs. Comments very welcome, especially in the DNS area. My plan is to submit this to the IDR WG at the IETF in December, but it's an individual contribution at this point. To Be Multihomed: Requirements & Definitions draft-berkowitz-multirqmt-00.txt You can FTP or HTTP it from: ds.internic.net/internet/drafts/draft-berkowitz-multirqmt-00.txt 2. Abstract As organizations find their Internet connectivity increasingly critical to their mission, they seek ways of making that connectivity more robust. The term ''multi-homing'' often is used to describe means of fault-tolerant connection. Unfortunately, this term covers a variety of mechanisms, including naming/directory services, routing, and physical connectivity. This memorandum presents a systematic way to define the requirement for resilience, and a taxonomy for describing mechanisms to achieve it. Multiple mechanisms may be appropriate for specific situations, including DNS, BGP, etc.

1 0

Re: New MAE-EAST
by Al Roethlisberger 08 Nov '97

08 Nov '97

At 08:33 PM 11/5/97 -0500, you wrote: > > Paul, > > I have not spoken with you before, so I do not know if your > posting below is meant in a literal, nonfacetious manner. > >> > With all of the problems with MAE-EAST..... >> > >> > Any plans from anyone to create a ATM exchange point in the DC area? > > For what it's worth, I do understand that there is a plan to create > an ATM exchange point in the DC area, at speeds exceeding those > currently available. > >> Given the latency we've seen over some ATM backbones, > > The latency increased in network areas that are switched is generally > (by all but the zealots) given to be less than that of comparable > layer three data moving topologies. > > The latency induced by several providers claiming an ATM backbone > is generally attributable to an error: they leave off one important > word -- shared -- . The latency about which I assume you speak is > caused by large amounts of queuing. This queuing is demanded by network > oversubscription. The latency introduced by the oversubscription > is consistent with any oversold network. > Perhaps he is referring to latencies that some beleive is incurred as ATM 'packet shredding' when applied to typical data distributions encountered on the Internet that fall between the 53byte ATM cell size and any even multiple thereof? Some reports that I have seen show a direct disavantage for data where a large portion of 64byte TCP ACKS, etc. are inefficiently split among two 53byte ATM cells, wasting a considerable amount of 'available' bandwidth. i.e. one 64byte packet is SARd into two 53byte ATM cells, wasting 42bytes of space. If a large portion of Internet traffic followed this model, ATM may not be a good solution. I am not an authority on this position, so feel free to dispute, but perhaps that is one latency factor to which he was referring?

6 5

Re: BGP/Multihoming
by Paul Ferguson 08 Nov '97

08 Nov '97

Here is a good reference/place to start: http://www.netaxs.com/~freedman/multi.html - paul At 11:48 AM 11/6/97 +0800, Michael R. Poyaoan wrote: > >The diagram below describes our current set-up: > >* We have two default routes via BGP with MCI (L1 and L2) for outgoing > traffic. >* The two MCI links are configured to load share incoming traffic thru the > use of MEDs. > > AS701 > +--------+ > | UUNet | > +--------+ > | > AS3561 | > +-------+ +--------+ > | MCI | | UNA | AS10275 > +-------+ +--------+ > | | | > | | | > | | | > L1| |L2 L3| > | | AS6648 | > | | +----------+ | > | +---| | | > | | Sky |-----+ > +------| | > +----------+ > >Questions: > >1. How can I use the third link for default routes? Is static routing > the only solution? > >2. Is it possible to load-share outgoing traffic between two different > ASN's? How? > >3. How can I unclude the third link for load-sharing incoming traffic? > >Please reply privately. > >Thanks, >--------------------------------------------------------------------------- >Michael R. Poyaoan email: mrp(a)skyinet.net >Network Operations Center voice: +63 2 411-2005 >Sky Internet, Inc. fax: +63 2 411-2003 >--------------------------------------------------------------------------- > > >

3 2

Announcing The New "MAE-EAST"
by Kent W. England 07 Nov '97

07 Nov '97

At 12:46 PM 11/5/97 -0800, Adam Hersh wrote: >With all of the problems with MAE-EAST..... > >Any plans from anyone to create a ATM exchange point in the DC area? > >-Adam Hersh > > In the true MAE spirit, I rented a parking place right next to the door to MAE-East. I've parked a UHaul trailer in that space with a really big Ethernet switch on it. Power comes from an extension cord to the ceiling light. Since they never turn off the lights, I have 24x7 power available. Ventilation comes from passing traffic and I have a backup fan in my truck. Aircraft avoidance is made possible by rapid mobility (I keep the motor on my pickup running.) Forklift upgrades are entirely avoided since I already have a pickup truck. Marketing is simple. "Everyone you never heard of is already connected to Kent's Trailer Exchange." If we decide we don't like the MAE-East garage we can simply move it, if your drop cables are long enough. I avoid latency problems by running the switch at faster than light speeds. There is no packet shredding at Kent's Trailer Exchange, although from time to time I rewrite packets and turn all the IP options on, just for fun. Statistics are quite easy too. I've already published the traffic growth charts for the next 12 months. see http://www.6SigmaNets.com/trailer-exchange/business-plan/index.html In short Kent's Trailer Exchange has everything you could want in a slapped-together public exchange point. Next time you leave MAE-East, drag a fiber drop on your way out the door and meet me at the trailer. We'll have you up and running in a giffy. Oh, and bring a cup of hot coffee. It's getting damned cold in the garage this time of year. --Kent President, CEO, Chairman, Chief Architect, Webmaster & Publicist Kent's Trailer Exchange An Instant Idea Brought to you by Six Sigma Networks

3 2

Re: Cyberpromotions plans to acquire or merge with a national ISP?
by Sean Donelan 07 Nov '97

07 Nov '97

>Sorry Randy, there's nothing in this you can cut or paste into your Cisco. >But I think that peering with a Cyberpromotions-partnered ISP would be a >huge operational problem based on reports of AGIS's experiences with them, >and I wanted to give everyone a heads-up that Cyberpromotions appears not >to be ready to fold up their tent and stop spamming us all quite yet. Quoting a phone company interconnection agreement: "The Telephone Company will administer its network to ensure the provision of acceptable service levels to all telecommunications users of the Telephone Company's network services. The Telephone Company maintains the right to apply protective controls on any traffic that it carries over its network in order to prevent unsatisfactory performance to other users." Time to talk to the lawyers again, sigh... > says three compaines are being considered, and all have peering > agreements through 2006 or 2008. "That allows us time to make this Since almost all peering agreements are covered by NDA's, who in the know could refute him. Hint: Does a 10 year peering agreement sound too good to be true? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

5 4

Re: Architectural Solutions to Internet Congestion Based On SS7 and Intelligent Network Capabilities
by csilva＠notes.cc.bellcore.com 07 Nov '97

07 Nov '97

carl ford at bellcore is doing more work on this, please e-mail him for more info.... carl silva 908-699-7850 To: Alan Gebele/Bellcore@Bellcore, Carl S. Ford/Bellcore@Bellcore, Carl L. Silva/Bellcore@Bellcore cc: From: Luis D. Arango/Bellcore Date: 11/06/97 04:44:34 PM Subject: Re: Architectural Solutions to Internet Congestion Based On SS7 and Intelligent Network Capabilities Folks, As expected, fyi, rave review from the net community. Lou To: tli @ juniper.net cc: ferguson @ cisco.com, nanog @ merit.edu (bcc: Luis D. Arango/Bellcore) From: kc @ nlanr.net Date: 11/06/97 05:41:46 AM PST Subject: Re: Architectural Solutions to Internet Congestion Based On SS7 and Intelligent Network Capabilities > The operative concept in this paper is 'telephone networks'. > > "Architectural Solutions to Internet Congestion Based On > SS7 and Intelligent Network Capabilities" I particularly liked the myopic use of the term "Internet Congestion". And here I thought that they had a solution for MAE-East.... ;-) I think the paper would have been more accurately titled: "Kludges to get around modems that don't say goodbye." or "We never should have introduced flat rate local dialing. What now?" ;-) ;-) tony -- i almost went catatonic when i tried to read that paper -- check out sentence number One: The explosive growth of the internet has created problems for the Public Switched Telephone Network (PSTN), which for the forseeable future will provide the majority of users with internet access via dialup modems. i love how their phrasing it like they have this acute perception about the market demands. as though we're all still using modems by choice. as though THEY aren't the ones limiting us to this silly analog crap, despite that they already have perfectly high quality dedicated copper pairs into customer premises. the only reason Anyone is still using a modem is cause the PSTN can't seem to Get With The Program and learn how to speak Internet (speak it, hell, they can't even Spell it with a capital I in this paper. i think we should all lowercase pstn from now on.) (ok so that made less sense coming from me. whatever.) if it weren't so depressing it would be amusing, the attitude throughout this paper: that the PSTN views Internet traffic as something to quarantine off to its own network (keep it away from the precious lucrative pstn) this paper provides no architectural solution to, nor even insight into, Internet congestion. not even solutions that could clearly increase RBOC revenues (what morons) instead it draws Magic Sphere around the telephony network, shielding it from the Horrible Intimidating Internet, without any consideration of how they might be able to participate in evolving the Internet efficaciously. ok so maybe we weren't expecting some huge breakthrough from them, but did they have to so *Vividly* confirm my worst fears about the prevailing archaic pstn mindset. my favorite part was one of their possible solutions for how to divert circuit calls to ISPs based on some numbering scheme: to obtain all ISP and on-line service provider (OSP) telephone numbers, and configure office-based 'triggers' for these numbers. oh yeah. that'll work. all the phone numbers of all the ISPs. yum. the boggling part is that they're *already* openly assuming the need for an additional packet switched network No Matter What. and the pstn has already dedicated Always-On copper lines from customers to COs -- so their plan is to do some heuristics on the signals coming in from the copper pair, and turn it into a transient fixed bandwidth circuit. brilliant leap of logic right into the abyss, how did they manage that. can't they come up with a more broken model? (no, i don't want to know) i just don't see what's so repulsive to them about just building a PSI(nternet)N, colocating routers, then using the already dedicated circuits to customer premises to access it. (i guess that's what @home thought too; they seem to have at least gotten that part right) they're adding so much Kruft to their system just to avoid moving to a more capable one there is something so Deeply Wrong with this picture where's Kuhn when you need him maybe we should get michael moore to do a movie about it (i know, you all were planning to wait for the movie rather than read that article anyway. wise souls.) k

1 0

BGP/Multihoming
by Michael R. Poyaoan 07 Nov '97

07 Nov '97

The diagram below describes our current set-up: * We have two default routes via BGP with MCI (L1 and L2) for outgoing traffic. * The two MCI links are configured to load share incoming traffic thru the use of MEDs. AS701 +--------+ | UUNet | +--------+ | AS3561 | +-------+ +--------+ | MCI | | UNA | AS10275 +-------+ +--------+ | | | | | | | | | L1| |L2 L3| | | AS6648 | | | +----------+ | | +---| | | | | Sky |-----+ +------| | +----------+ Questions: 1. How can I use the third link for default routes? Is static routing the only solution? 2. Is it possible to load-share outgoing traffic between two different ASN's? How? 3. How can I unclude the third link for load-sharing incoming traffic? Please reply privately. Thanks, --------------------------------------------------------------------------- Michael R. Poyaoan email: mrp(a)skyinet.net Network Operations Center voice: +63 2 411-2005 Sky Internet, Inc. fax: +63 2 411-2003 ---------------------------------------------------------------------------

2 1

Cyberpromotions plans to acquire or merge with a national ISP?
by Paul A Vixie 07 Nov '97

07 Nov '97

Background: AGIS cut them off, they're suing AGIS, they're also making noises about starting their own backbone. In a USA Today article (05 Nov) they got more specific about their plans. Sorry Randy, there's nothing in this you can cut or paste into your Cisco. But I think that peering with a Cyberpromotions-partnered ISP would be a huge operational problem based on reports of AGIS's experiences with them, and I wanted to give everyone a heads-up that Cyberpromotions appears not to be ready to fold up their tent and stop spamming us all quite yet. Best quote from below: "AGIS engineers expressed skepticism that a deal like the one Wallace describes would be possible; even if one of the smaller backbone companies agreed to team up with him, backbones must negotiate to exchange traffic at "peering points" and many would refuse." "But Wallace's partner in the venture, Walt Rines, another e-mail marketer and president of Quantum Communications of Stratham, N.H., says three compaines are being considered, and all have peering agreements through 2006 or 2008. "That allows us time to make this thing happen so everybody's happy," he says. "We know things have to change." ------- Forwarded Message Newsgroups: news.admin.net-abuse.email Subject: USA Today Article..... Date: Thu, 06 Nov 1997 06:21:51 GMT OK, for those who couldn't or didn't want to get the November 5, 1997 USA Today article on Scamford...here are some excerpts. Section D, page 4D. Two articles by Leslie Miller, one doesn't give credit. A big picture of Scamford sitting on the floor of his office, he's holding a mail box with the letter EMAIL on the side. He is surrounded by computer equipment and cheap church dinner looking tables. "On-line lament: Deliver us from junk email" Talks about hijack servers, AOL lawsuits.... A real good tidbit here, something most predicted about the USA Today survey.. "Despite the annoyance, many users (55% in a Harris Survey in April) think spam is no big deal. "Just hit the delete button," said numerous respondents to a recent informal servey on USA TODAY's Web site." "Despised 'Spam King' sends no regrets" "He expects to sell more than 2 million in marketing-related products this year. And though temporarily sidelined, he says he's within days of announcing a deal that will give him "ownership and control" of one of the 20 or so providers whose networks make up the "backbone" of the Internet. The agreement will allow his company "to connect without fear of getting the lines turned off." "AGIS engineers expressed skepticism that a deal like the one Wallace describes would be possible; even if one of the smaller backbone companies agreed to team up with him, backbones must negotiate to exchange traffic at "peering points" and many would refuse." "But Wallace's partner in the venture, Walt Rines, another e-mail marketer and president of Quantum Communications of Stratham, N.H., says three compaines are being considered, and all have peering agreements through 2006 or 2008. "That allows us time to make this thing happen so everybody's happy," he says. "We know things have to change." [rest of article skipped] ------- End of Forwarded Message

2 1

Re: YKYBHTLW
by Jay R. Ashworth 07 Nov '97

07 Nov '97

[CC of a followup to your news posting] On Sun, 02 Nov 1997 15:37:09 -0800, Matthew Sayler wrote: > You know you've been hacking too long when you read "Evergreen Point > Floating Bridge" as "Evergreen Floating Point Bridge".. :-) Even routers don't need floating point... why would bridges need it? Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592

1 0