- Test - lists.nanog.org

Re: AGIS/DIGEX
by Mark Borchers 30 Oct '96

30 Oct '96

> 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. Mark Borchers InfiNet Network Engineering NOC: (757) 624-2295 ext. 3007

6 6

Re: A proposal for reducing routes due to multihoming
by Tony Li 30 Oct '96

30 Oct '96

The first time I heard this idea was last year, from Noel Chiappa. Joel Halpern and I spent a while discussing it and decided it would scale surprisingly well. However, why would the major providers be motivated to implement it at all? Because it reduces routes... and it has other benefits, such as allowing subscribers to change providers within the provider group without renumbering. If you still have a copy of Yakov's ID on stratum based aggregation, you might check that out. Sorry, it's expired and I don't have a copy myself. Yakov and I are discussing overhauling the document and resubmitting it. Tony

1 0

Re: AGIS/DIGEX
by Tony Li 30 Oct '96

30 Oct '96

Others have said this, but it really does seem like there needs to be pricing that allows for varying degrees of peering. It's a big jump from "you pay for every byte" to "you pay us nothing". There are providers who should fall between these extremes. Rest assured that in the fullness of time, such providers will exist. The market will force it. In the mean time, smaller providers who would like to encourage such practices have a rather persuasive inducement towards such a behavior: on your peering application, attach a check. Tony

1 0

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