October 1996 - Test - lists.nanog.org

Re: AGIS/DIGEX
by Steve Noble 30 Oct '96

30 Oct '96

At 10:36 AM 10/30/96 +0500, you wrote: >> AGIS has made it a 5-NAP requirement - and the AADS and PacBell NAPs >> are not the easiest to get into on 1-day notice. >> >What I heard them say was that you had to peer with them in every NAP >where they were present...implying that if they go into a sixth NAP, >their peering requirement increases. > actually peter said something about if you weren't at every nap they were at, there might be problems (or they have seen problems) getting traffic to/from you. That's kind of a scary (and unrealistic) thought imho to think that their/your/the internet is so unstable that out of 6 paths only 1 functions correctly. .-[ Steve Noble / Sr.Network Admin ]-. - Exodus Communications / steve(a)exodus.net - - v(408)486-5024 / f(408)486-5001 -

1 0

RE: A proposal for reducing routes due to multihoming
by Peter Cole 30 Oct '96

30 Oct '96

I think you miss the whole reason that we want multihoming. We want higher reliability. If you use one block for both providers say Sprint and MCI then when Fortworth takes another fiber cut (happens every few months) Sprint will bitbucket traffic that arrives inside their network for my system. Or if I see that one provider is flapping nationwide then I withdraw my routes and down the interface to that provider. That is how I see higher reliability. ---------- From: Alexis Rosen[SMTP:alexis@panix.com] Sent: Tuesday, October 29, 1996 10:27 AM To: nanog(a)merit.edu Subject: A proposal for reducing routes due to multihoming Bill Simpson claims that this idea is ~10 years old, but if so perhaps it's time to air it again. I thought of this during the route flap BOF at NANOG, mentioned it, and nobody came up with any immediate reasons why it wouldn't work, so I'm sending it to the list for further consideration. It's dead simple, really: Assign address blocks to pairs of providers. Both providers announce those blocks all the time, and assign addresses out of those blocks to customers who multihome between those two providers. Now, clearly this won't help all multihomed nets, because you can't possibly provide netblocks for all provider pairs- you'd have n*n-1 blocks instead of n, for n providers- but you can optimize for common cases. In particular, any two providers who will state that they are going to coordinate multihoming get a netblock. You can also limit this, at least in the beginning, to some smallish group of providers (such as the big six/seven/whatever, though that's probably a poor criterion). Any provider who wants to start doing this today can, of course, simply by declaring that part of its aggregate is now jointly owned by another provider, and that other provider announcing that part. This isn't really a change in technology so much as it is a change in bookkeeping: by putting all the multihomed nets together, both of the providers of those multihomed nets can aggregate announcements. But the benefit is real: fewer routes, and no route flaps when any single multihomed customer falls off the net. You reach breakeven on # of routes as soon as any pair of providers has two customers doing multihoming. That makes this scheme beneficial both to customers and to providers. So, any takers? /a

1 0

Re: Peering Policy ( was Re: AGIS/DIGEX )
by owen＠DeLong.SJ.CA.US 30 Oct '96

30 Oct '96

> So far from what I have gathered, everyone is afraid of being used as a > transit point. There is a very simple solution available which I can't > figure out why people are not using. > > Both peers charge each other for the bits being peered. So now if one > peer is being used as a transit point, then they get compensated for it. > > Eg > > AAA BBB > 15443621 bits -> 15443621 bits > 20000000 bits <- 20000000 bits > > This is not simple or correct. For example, we host MicroSoft's download site for Internet Explorer. Should we pay the price for all the bits we deliver to AAA in response to AAA's customers requests for Internet Explorer? I don't think so. > Difference 4556379 bits additional sent from BBB to AAA > > Applying lets say 1 cent per 100 bit charge, AAA gets $455.64 from BBB > > Simple!!!! > > Now with this kind of peering arrangement, no one has to be worried about > being used as a transit point -- infact they will want to be used as a > transit point. > Why heck, it would even make the $5/month personal accounts proffitable, as you would get reimbursed by all the ISP's your customers download from. > This will also allow medium sized ISPs to peer with each-other. > > So here is my question -- why is this kind of arrangement not being used > anywhere??? > Because it's a broken idea. > Pritish > > > > Owen

1 0

Re: AGIS/DIGEX
by Mike Trest 30 Oct '96

30 Oct '96

Enke, Message to Paul but posted to NANOG. Therefore, my comments: >(1) CIX is an association of ISPs. The CIX Inter-exchange puts > CIX in direct competition with its members (ISPs) for > customers. Is there a contradiction here? Yes & No. A CIX member is not forced to have a circuit at CIX. There are members who are not ISPs. Perhaps the mutual benefits of the association out weigh any individual negative aspects of working together as a group. >(2) The CIX Inter-exchange has been used by some to bypass > peering policies. I am wondering if the CIX Inter-exchange > remains a viable option in the peering policy review. You pose this question as if the CIX is a problem for the Internet peering policy situation? If anything, the CIX peering policy remains a clear, unambiguous, statement working for the good of its members and for the good of the Internet. As long as the membership gives this kind of direction to the current CIX leadership (Bob, Barbara, et.al.) then Paul is doing his job right by making the best technical moves with the resources available. (Which sounds like a lot of us,eh?) >(3) Today there are quite a few inter-exchanges in the Bay Area > that are superior (in terms of tech. and richness in connectivity) > than the CIX Interexchange. Is it fair to say that the > CIX Inter-exchange has fulfilled its historical mission and > is no longer needed? I suppose that is a question for the membership. However, they appear to support the recent technical upgrade to the IX as well as supporting the legaslative and other promotional activities of the CIX. ..mike.. Mike Trest, ATMNET Voice: 619 643-1805 5440 Morehouse Drive Fax: 619 643-1801 San Diego, CA USA 92121 EMAIL: trest(a)ATMnet.net

1 0

Re: Provider credibility - does it matter? was Re: Inter-provider relations
by Andy lague 30 Oct '96

30 Oct '96

At 03:02 AM 10/27/96 MET, Peter Lothberg wrote: >> So what's the problem? Basically, one organisation, Ebone, which >> operates a fairly large pan-European net, won't peer with others. This >> means that European customers connected to non-Ebone connected >> providers like Global One lack European connectivity without going >> through the US. Ebone provides great connectivity at cost, but the big >> US NSPs making presences in Europe naturally don't want to buy >> bandwidth from someone like Ebone. We'll see what happens. Ebone is not the only way to get European connectivity without going to the US. There are many exchange points in Europe providing local traffic exchange. Global-One participates in some of these with more in the works. Ebone is a good last resort (not to be read as default) path to obscure destinations or to networks that will not peer with commercial networks. >I don't think this is correct. Ebone peers with other pan-european >networks of comparable size, IBM, BT and EUnet comes to my mind. > >G1 is a customer of Ebone and connects in Paris. > Correct. Also Stockholm. Regards, Andy - speaking as a former Global-One employee

3 2

A proposal for reducing routes due to multihoming
by Alexis Rosen 30 Oct '96

30 Oct '96

Bill Simpson claims that this idea is ~10 years old, but if so perhaps it's time to air it again. I thought of this during the route flap BOF at NANOG, mentioned it, and nobody came up with any immediate reasons why it wouldn't work, so I'm sending it to the list for further consideration. It's dead simple, really: Assign address blocks to pairs of providers. Both providers announce those blocks all the time, and assign addresses out of those blocks to customers who multihome between those two providers. Now, clearly this won't help all multihomed nets, because you can't possibly provide netblocks for all provider pairs- you'd have n*n-1 blocks instead of n, for n providers- but you can optimize for common cases. In particular, any two providers who will state that they are going to coordinate multihoming get a netblock. You can also limit this, at least in the beginning, to some smallish group of providers (such as the big six/seven/whatever, though that's probably a poor criterion). Any provider who wants to start doing this today can, of course, simply by declaring that part of its aggregate is now jointly owned by another provider, and that other provider announcing that part. This isn't really a change in technology so much as it is a change in bookkeeping: by putting all the multihomed nets together, both of the providers of those multihomed nets can aggregate announcements. But the benefit is real: fewer routes, and no route flaps when any single multihomed customer falls off the net. You reach breakeven on # of routes as soon as any pair of providers has two customers doing multihoming. That makes this scheme beneficial both to customers and to providers. So, any takers? /a

5 5

5 NAPs Any savings?
by Deepak Jain 30 Oct '96

30 Oct '96

Here is the question that occurred to me. If we set a requirement to be at 5 NAPs, and we don't peer with anyone who isn't at 5 NAPs, and we only peer with like 4 networks that qualify, aren't we essentially talking about using GigaSwitch or ATM switches as private interconnects? [barring the defaulting issue on FDDI] If whole point is to exclude networks due to a number of technical reasons why go to 5 or 20 NAPs when private connects would serve the same purpose? Or is it some kind of bragging thing where a network can say "We went to the time and expense of engineering connections to 5 NAPs and now no one qualifies for peering with us." Wouldn't the obvious question be, "Why did you bother then?" For several organizations it isn't the money that is really a question with multiple NAPs, but the marginal value of the next NAP after you are already at 3 or 4 whatever is considered acceptable/comfortable. [Economic theory, sorry] Anyone agree? -Deepak.

3 2

Tip of the Day - Velcro tie-wraps
by Stephen Stuart 30 Oct '96

30 Oct '96

If you read this while you're at the Ann Arbor NANOG meeting and wander over to the back corner of the auditorium, I'll show you one. Velcro tie-wraps are made by Textol Systems, Inc. You can check them out at http://www.textol.com/. No, I don't own stock in the company; I just think these things are brilliant, and since we all work with wires (or their moral equivalents in the "things that need to be tie-wrapped" category), I thought I'd share. They come in spools of 900; peel once off, trim to fit, and use it over and over again. Stephen - ----- Stephen Stuart stuart(a)pa.dec.com Network Systems Laboratory Digital Equipment Corporation

3 2

Re: Inter-provider relations
by Alex Rubenstein 29 Oct '96

29 Oct '96

>Now Peter goes one step further and because of the fact that he had an >unpleasant conversation with a competitor he suggests that the competitor >may be planning criminal acts. However Peter shows no evidence why he >would think that way except for the fact that he personally dislikes the >president of this competing company. Uhh.. Who else here considers cais.net a competitor to agis.net ? :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Alex Rubenstein - alex(a)nac.net - Senior Engineer net @ccess corporation, 104 broadway, denville, nj 07834 201-983-0725 -- 201-300-9047 Fax -- http://www.nac.net ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

1 0

Re: AGIS/DIGEX
by Sanjay Dani 29 Oct '96

29 Oct '96

> > This is just a guess, but I suspect Digex will lose more customers if > > they cannot connect to Agis than the other way around. However I am not > > intimately familiar with either networks customer base. > > > > -Deepak. > > Digex has sec.gov and other .gov sites... - and a lot of other business > historically in the DC area. Those are of interest. > > AGIS has a number of ISPs and some RBOCs as customers of note. Am I missing something? traceroute to web1.digex.net (205.197.247.33), 30 hops max, 40 byte packets 1 us-cup-2.webpros.com (206.127.192.7) 8 ms 8 ms 2 sc01-c0.MainStreet.Net (199.245.73.1) 17 ms 19 ms 3 mae-west.agis.net (198.32.136.21) 36 ms 5 ms 4 198.32.136.39 (198.32.136.39) 9 ms 11 ms 5 198.32.128.67 (198.32.128.67) 13 ms 12 ms 6 h14.t96-0.Denver.t3.ans.net (140.223.9.18) 35 ms 39 ms 7 h11-1.t24-0.Chicago.t3.ans.net (140.223.25.21) 100 ms 101 ms 8 h14.t40-0.Cleveland.t3.ans.net (140.223.41.9) 102 ms 96 ms 9 h14.t48-0.Hartford.t3.ans.net (140.223.33.14) 104 ms 107 ms 10 h11.t32-0.New-York.t3.ans.net (140.223.33.129) 107 ms 104 ms 11 enss219.t3.ans.net (140.223.33.130) 96 ms 93 ms 12 digex.sprintnap.net (192.157.69.42) 131 ms 129 ms 13 phl1-core1-h1-0.atlas.digex.net (165.117.50.77) 158 ms 155 ms 14 dca3-core1-h1-0.atlas.digex.net (165.117.50.69) 149 ms 200 ms 15 dca1-core4-h1-0.atlas.digex.net (165.117.50.65) 228 ms 107 ms 16 dca1-core6-f1-0.atlas.digex.net (206.205.242.1) 125 ms 126 ms 17 web1.digex.net (205.197.247.33) 146 ms 181 ms % date Tue Oct 29 18:04:44 PST 1996

2 1