- Test - lists.nanog.org

Re: Best way to deal with bad advertisements?
by Sean Donelan 30 Sep '96

30 Sep '96

> Just to add a bit to that, the US Government could force providers > to peer with all providers meeting certain requirements (enter > telco history) but I think there would be difficulty requiring > them to peer with non-US companies. Actually the US Government already has such a policy. Buried deep inside the original NSF NAP solicitation was the requirement any provider must peer with any other provider connected to all three priority NAPs, or it would not qualify as an NSP for NSF connection grants. There was no requirement for minimum connection speed to a NAP or between the NAPs to qualify as an NSP. This was to keep the old NSF mid-level networks from losing connectivity with each other if they happened to choose different NSPs. I'm guessing the NSF connection program has wound down by now, so this isn't that much of a factor any more. But there is no reason why the same conditions couldn't be imposed on other government funds for network connectivity. Nor is there anything preventing other customers from choosing their provider on the same basis, or putting similar conditions in their contracts. If customers don't realize that different providers have different interconnection policies, they may not know its something they should consider. I used to recommend UUNET to customers in part because they peered with lots of other providers. Markets are usually better at sorting these things out than governments, as long as the consumer has all the information to make a decision. But if you like involving government, the big providers usually have more restrictions on them because they like getting government money. vBNS and ICM are two examples that could lead to interesting peering requirements from the government on the providers. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Re: Advice on dealing with Sprint
by William Allen Simpson 30 Sep '96

30 Sep '96

Coming back to an old topic from whence we diverged, my advice would be _not_ to connect or multihome with Sprint unless they accept you as a peer and share the cost. Earlier, we have learned that Sprint doesn't multihome properly, as it deliberately ignores paths to its own "customers" seen from other ISPs even when its own lines are down. You learned that they have restrictive policies on routers. And more recently, we learned that Sprint has extremely restrictive policies on peering (exchanging routes). There really isn't much point to multihome with Sprint except to load share directly to Sprint's customers. You don't get any of the other benefits of redundancy. Why bother paying for the link and Sprint for the privilege? I can tell you, since my upstream provider switched a few weeks ago from multihome with Sprint and MCI, to nap.net and MCI, we've had _much_ better service! When nap.net has had problems, multihoming has actually worked correctly.... And multihoming with MCI and AlterNet seems to work well together, too. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Re: Best way to deal with bad advertisements?
by salo＠msc.edu 30 Sep '96

30 Sep '96

> Date: Mon, 30 Sep 1996 6:21:11 -0500 (CDT) > From: Sean Donelan <SEAN(a)SDG.DRA.COM> > To: nanog(a)merit.edu > Subject: Re: Best way to deal with bad advertisements? > > > Just to add a bit to that, the US Government could force providers > > to peer with all providers meeting certain requirements (enter > > telco history) but I think there would be difficulty requiring > > them to peer with non-US companies. > > Actually the US Government already has such a policy. Buried deep > inside the original NSF NAP solicitation was the requirement any > provider must peer with any other provider connected to all three > priority NAPs, or it would not qualify as an NSP for NSF connection > grants. The solicitation, NSF 93-52, specifies that "To qualify for NSF support for NSP attachment and/or for the provision of interNAP connectivity, a regional network must attach to an NSP that connects all NSF- specified priority NAPs." (Section III.F) Note the use of the term "connects." I didn't re-read the whole solicitation, but I believe it is silent on the topic of peering. There were some conversations on this topic after the fact, so something reguarding peering might be in some of the relevant cooperative agreements. However, these agreements might apply only to research and educations traffic. > There was no requirement for minimum connection speed to > a NAP or between the NAPs to qualify as an NSP. > [...] Solicitation NSF 93-52 specifies "Networks attaching to NAPs must operate at speeds of 1.5 Mbps or greater and must be able to switch both IP and CLNP packets." (Section III.F). -tjs

1 0

Re: Peering versus Transit
by William Allen Simpson 30 Sep '96

30 Sep '96

Thank you for the beginnings of a more focused discussion on these hard issues! I particularly thank Bill Woodcock for a much more thorough treatise with diagrams which elucidates the major issues. I am convinced that his argument is substantially correct. The limitation on interconnection is both a technical and socially undesirable end. Sean Doran advanced some thoughtful solutions for these problems (although it took more than one reading for me to understand). So, given that the current policies of large providers promote network congestion, poor topology engineering, and discourage competition, what policies should we create to fix this problem? Wouldn't XP policies more in line with those of CIX be to everyone's advantage? As Sanjay Dani correctly states, "if these issues are not resolved within the ISP community it won't be too long before courts force the issues." What technology do we need to implement these better policies? Is expanding BGP/IDRP for Sean's AS metric suggestion already being done? Another issue that was raised was the cost of exchanging bilateral routes with more ISPs at an XP, and inability to trust the small ISPs to properly configure. In reality, we have seen that even large ISPs are badly configured from time to time, and therefore the "smallness" is a bogus point, although the trust issue remains. Wouldn't that be solved by having each ISP peer with the XP instead of every other ISP, reducing from N**2 to N? Cannot the ISPs trust the XP to be properly configured? Isn't this what is already done with the RA project? WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Re: Peering versus Transit
by Barney Wolff 30 Sep '96

30 Sep '96

> From: Sean Doran <smd(a)cesium.clock.org> > Date: Sun, 29 Sep 1996 23:41:28 -0800 > > In one hypothetical case, consider a large provider that > is being dumped upon by another provider which is > outraged that the large provider consistently refuses to > peer with them. This could have the result of pushing > traffic inbound towards the larger provider over the > threshold at which the difficulties in buffer management > become highly noticeable, which leads to some 15% packet > loss at times for customers of the larger provider trying > to make use of that exchange point. (Leaving out the over-the-water case for the moment) I don't understand. Let's hypothesize an exchange point at which NSPs S, M, U all meet and peer, and which also includes N, the new provider who buys transit from U and somehow (How? Maybe by peering with M) has a router on the switching fabric at the exchange point. Packets from N for S's customers therefore are supposed to flow from N's router to U's router to S's router, yes? One day, N decides to save the double hop through the switching fabric, and puts in a static route for (some of) S's customers so that packets flow directly from N's router to S's router. Certainly this is unauthorized. But how has the rate of packets into S's router changed? Moreover, the return path is still S->U->N, so there's no reason to expect that the packet rate through S's router will be different in and out. All this would be quite different if N pointed default to S, I agree. It would also be different if for some reason S did not advertise all of its customer routes to U's router at this particular exchange point. Is that actually done, and is this relevant to the over-the-water case? Barney Wolff <barney(a)databus.com>

1 0

Third party routes
by Sean Donelan 30 Sep '96

30 Sep '96

>There are two ways to have packets go where no BGP routes are announced -- >by adding bogus static or whatever routes or by pointing default. Both >are malicious. Note that accepting third party routes is also something >not generally welcomed. If you're not given routes you're _not_ expected >to send your packets. Consider that a "no trespassing" notice. MCI has found an intereesting variant on this. Whenever MCI has backbone problems in Chicago, DRA suddenly sees all sorts of inbound traffic from MCI at mae-east and mae-west. DRA usually ends up sending the outbound traffic back through CIX since MCI won't announce their routes to DRA at mae-east and mae-west. >Backbones are _private_ property. As such the operators are in their >right to demand that others leave their equipment alone. True, but who has deeper pockets when mistakes happen. If you are a multi-billion dollar provider, and one of your engineers has a late night routing 'oops', having an agreement already in place with other providers can mitigate some of risk. Do I get to sue MCI for the traffic they send DRA at mae-east and mae-west without an agreement? In the mean time, consider all those routers at the exchange points you don't peer with as potential legal lottery winners waiting for the first wayward packet to violate your "no trespassing" notice. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: Best way to deal with bad advertisements?
by Sean Doran 30 Sep '96

30 Sep '96

Neil McRae writes: | Its to do with what the *CUSTOMER* [remember that person that makes it all | possible] wants. This is the key point about this industry. Traditional engineering is not used to building things based almost exclusively on the vagaries of customer demand, and moreover, it is not well-suited to the degree by which the wants of customers shifts on the Internet. It may be www.netscape.com today; it might be something else tomorrow. All it might take is a well-timed advertising campaign, and a network designed for reaching www.netscape.com becomes frustrating to the majority of one's customer base. Unfortunately, from time to time, this key point seems to escape traditional engineers and beancounters used to them. One can observe the places in which this is or becomes endemic, simply by tracking market-share. Sean.

2 1

Re: Peering versus Transit
by Sean Doran 30 Sep '96

30 Sep '96

| Where a phone company exchanges traffic with another phone compnay | and there is some form of settlement involved, this cannot apply | to the IXs until some serious technology breakthroughs happen in | terms of measurement of IP. I am the last person to argue for fine-grained measurement of traffic. However, the practice of adjusting prices by a gross estimate of how much traffic is moved is venerable in the commercial Internet (it goes back to at least Alternet's T1-LV service, which I remember being introduced when I was at UUNET Canada a few years ago). I see no flaws in a seller saying, "hey, here's a threshold that you can't go beyond without paying more $$". Whether this is implemented by looking at link statistics over time and giving some warning that thresholds have been crossed, and that if they keep being crossed, the bill will become more expensive, or this is implemented by a router noticing that a threshold is being crossed and it dropping traffic (using, perhaps, a progressively aggressive RED, or tail drop, or dropping out of the biggest or newest flows, or whatever) automatically seems to be a detail to me. People into traffic-planning probably would tend to prefer the second implementation type over the first. Wide-scale deployment of things like RED gateways might change some of that, however. Moreover remember that most big-provider (telco) traffic is moving away from EPs these days, and that the fact that I was dealing with EPs was not an accident nor ignoring that particular sea change. Therefore, as I noted, the idea of pricing comes from whose customers scream. If your customers won't scream at all if you don't talk to X, but their customers will scream and look for a different provider, then you can charge X a great deal of money for each bit of bandwidth X requires to make X's customers happy. If the reverse is true, X can charge you lots of money for each bit of bandwidth. (Notice that the same is true wrt reachability). If, OTOH, both customer bases scream, it becomes somewhere between a game of chicken and a rational business agreement between competitors in agreeing upon who charges what price. You will note that among the very large providers, if any of them stop talking with any other, there will be screaming on both sides, and so far there has been both reactions (chicken and agreeing on pricing or bearing the burden of costs). Marketing and sales people do track how one is doing wrt increased or decreased sales, and ops folk do track how one is doing wrt scream about angry customers. A well-organized company will connect ops/marketing+sales with bean counters and engineers and come up with a consensus that should be good for the company. This is what's needed much more than fine-grained counting of traffic, in determining price points for "settlements". | Just to add to the confusion... Not really. Nobody in their right minds (hi Dr Cerf!) would ever seriously propose a bell-like settlement model that required answering any of the questions you posed. Sean.

1 0

Re: Peering versus Transit
by Barney Wolff 30 Sep '96

30 Sep '96

> Date: Sun, 29 Sep 1996 23:11:57 -0400 (EDT) > From: Nathan Stratton <nathan(a)netrail.net> > > Yes, but can we agree that dumping data to someons router at a NAP > without asking is steeling? Is it really the case that people with routers at exchange points actually consider a packet addressed to one of their own customers to be theft of service? So far, I note, we haven't heard any position expressed by any of the big folks, just by others outraged on their behalf. And of course, to be in a position to "dump data" on a router at an exchange, one must have one's own router there peering with *somebody*, right? So the problem, if there is one, is that not all pairs of routers at an exchange are necessarily allowed to communicate. ATM, anyone? (Gasp cough choke) Barney Wolff <barney(a)databus.com>

4 3

RE: Best way to deal with bad advertisements?
by Sean Donelan 30 Sep '96

30 Sep '96

>Because of problems like these, and the general trustworthiness of BGP4, >the re-evaluation of peer requirements have been all but forced upon major >backbone providers. Just imagine if you were UUNET, (or Sprint, or MCI, >or anyone with heavy backbone traffic in general) and one of your BGP4 >routing partners black holed part of your backbone... Refusing to peer with other providers doesn't prevent any of those things, it simply makes it harder to get the right people talking to each other. If you have a peering agreement with the other provider, you have a communications channel to resolve problems. If you don't talk to the other provider ahead of time, then when they blackhole your backbone, you have no clue who to call at the other provider to get it fixed. Besides, most of the major providers previously based the bulk of their peering 'requirements' on how many DS3s you had. Now most 'major' providers seem to have gone cold turkey. MCI, Sprint, and UUNET told me they won't peer with *anyone* new. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

6 9