- Test - lists.nanog.org

Re: What is the limit? (was RE: multi-homing fixes)
by David Lesher 29 Aug '01

29 Aug '01

{long thread...} Routing is a Ponzi scheme. You win by getting out early...or not playing. -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

Re: multi-homing fixes
by smd＠clock.org 29 Aug '01

29 Aug '01

Having lived for a while now in a small country, whose content for the most part is encrypted into a language only a few million people can read, I can assure you that there is nontheless alot of traffic flowing into the eyeballs of people living there (even though it's in other languages including unencrypted American), and the vast majority of that flow is paid for by the people living in that small country, whether they're paying-to-see or paying-to-be-seen. The heavy politics are all in who gets what piece of that cash flow. CNN has a local organization maintaining translated and locally-written material, for what it's worth. And anyway, with Akamizing and AOLephanting and so forth going on all over the place, they're a bad example for many other reasons. (Not least of which is that I get better news coverage elsewhere). But who would care if Bill's Bait Shop in California stopped being able to talk to a local national provider? And who would pay to fix that connectivity, if it were fixable only through the application of money? Who knows? (I'll take yer 50 cents though, Bill). Anyway, the whole idea of universal connectivity is a complete myth. Even when the connectivity is advertised at any given moment, it's not necessarily there. Multihoming in practice quickly reveals that "full routes" are not the same size and do not lead to the same goodput, as noted in part by Valdis. Sean.

1 0

RE: multi-homing fixes
by Roeland Meyer 29 Aug '01

29 Aug '01

|> From: Jonathan Disher [mailto:jdisher@ipix.com] |> Sent: Wednesday, August 29, 2001 1:11 AM |> |> > A BGP route seems to take approximately 155 bytes (based |> on "show ip |> > route summary" on a convenient GSR; YMMV). So a singe BGP |> route, at |> > $1000 per 128 meg (that is, at the absurd markup a vendor might |> > charge), you're looking 1/8 of a cent per route per router. That |> > doesn't count memory for a separate forwarding table; still, we're |> > not talking about a billable amount per router. |> |> You've forgotten CPU time (I've heard stories from my boss, |> who swear's |> he's older than dirt, of the days when people used to pay |> five, even ten |> whole dollars (wow Wally!) for the privilege of sitting in front of a |> teletype to type things in and get stuff spit out), |> $neteng's time to sit |> and type "sh ip rou x.y.z.0" or "sh ip bgp regexp xxxxx" to |> check for the |> existence of the prefix, and the labor to prepare, print, |> and mail the |> bill. The stamp alone, for a US destination, is a whole 34 cents! |> |> </sarcasm!> hehe Along with micro-allocations comes the issue of micro-payments. It costs ten times the face amount to cut a 50 cent check.

1 0

RE: multi-homing fixes
by Dave Israel 29 Aug '01

29 Aug '01

Sean, you male chauvinist pig. ;-) Actually, the following is a general rant, and not aimed at Sean. A BGP route seems to take approximately 155 bytes (based on "show ip route summary" on a convenient GSR; YMMV). So a singe BGP route, at $1000 per 128 meg (that is, at the absurd markup a vendor might charge), you're looking 1/8 of a cent per route per router. That doesn't count memory for a separate forwarding table; still, we're not talking about a billable amount per router. Now, if I am a service provider of any scale, and I do not accept your specific announcements, I run the risk of taking a sub-optimal path to you. There are lots of acceptable reasons for this to be. What if you are transitioning from provider X to provider Y, and have been given 60 days to renumber? Should you renumber on Transition Day and suffer the effects of waiting for nameservice? Or if you do mistrust your provider, or find it cheaper to connect to two smaller tier-3ish providers than one tier-1ish to get the same distance from the sites you need to reach? As a provider, I want to be able to offer the best connectivity to my customers, and even a little courtesy to the dear departed. I want to provide, and respect other people's provision of, these services. If you're not providing these services to people, then sure, filter your BGP announcements. On the other hand, if you're not providing these services, and you're not multihomed (and unless you have a /19 or so, part of the problem, in which case you have no place to bitch), what the heck do you need the table for? Assuming you're a good Internet player who has no need to be kind to your fellow providers, filter and dampen and save your time and memory. Heck, even if you are being kind, dampen; there's no reason to let a madly flapping network give your iBGP mesh a heart attack. But a stable route providing intelligent path selection to a network your customers may need to reach, or time for a site to renumber without any loss of connectivity? For an eight of a cent? I mean, come on. -Dave On 8/28/2001 at 08:41:40 -0700, Sean M. Doran said: > > "David Schwartz" <davids(a)webmaster.com> writes: > > | I'm not sure I believe that this tragedy of the commons exists where people > | route on allocation boundaries. If I make Sprint carry an extra route just > | for my little network, that helps all Sprint customers reach my little > | network. > > Cool, so you can get them to contribute a fraction of the 50 cents you owe me? > > Since I live downstream from Sprint, I tell you what: I'll give you > the first flap for free. And that's a generous offer, given that > your little network represents approximately zero percent of my traffic, > and I doubt I'll be complaining to my other personalities that I can't > get at your fascinating content without subsidizing your network's > globally-visible dynamicism. > > Sean. (who does, incidentally, subscribe to some pay-for-play > web sites, for example, which helps them pay for a part of THEIR > dynamicism. i must remember to ask for a 50 cent * n discount > at renewal time...) > > P.S.: the point here, since it's easy to miss, is that a clearing house > function is useful for containing complexity of negotiation, and > is currently being done by the RIRs on behalf of their owners > > business opportunity: a tool which reliably lets one decide if > prefix x is worth carrying in all its flapping glory, or whether > it should be bitbucketed until a bill is paid -- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet

2 1

RE: multi-homing fixes
by James Spenceley 29 Aug '01

29 Aug '01

> the point of 2xDS3 was specifically to get major services, > and not to get > every basement dual-homer. do the latter and you have the > same grazing > of the commons as we have today. major services often equals large pipe size, but not always. rather than setting the baseline at pipe size (which essentially indicates a cost), make the cost of the miroallocation high enough to discourage mass uptake by said backyard dual-homers. > randy -- James This Email is intended only for the use of the individual or entity named above and may contain information that is confidential and privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this Email is strictly prohibited. Before opening or using attachments, check them for viruses and defects. If you have received this Email in error, please notify us immediately by return email or telephone +61 2 8220 6000 and destroy the original message. Thank You.

1 0

RE: multi-homing fixes
by James Spenceley 29 Aug '01

29 Aug '01

David, > >Checking each prefix sounds like an awful lot of work, much better to > >bitbucket a entire countries prefixes if they collectively > don't account for > >0.nnn% of your traffic. > > Except that prefixes aren't allocated by country. Prefixes > are allocated > to ISPs (mostly). I guess i should have used a ;-). My point, If US operators only want to accept prefixes for 'free' from networks that account for a percentage of their traffic, your in a position to effectively blackhole much of the developing nations Internet. Is access to a countries Internet more or less important than access to a route with a different bit length or traffic level ? The size of prefix isn't necessarily the only basis for that prefixes value. > -drc -- James This Email is intended only for the use of the individual or entity named above and may contain information that is confidential and privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this Email is strictly prohibited. Before opening or using attachments, check them for viruses and defects. If you have received this Email in error, please notify us immediately by return email or telephone +61 2 8220 6000 and destroy the original message. Thank You.

2 1

RE: multi-homing fixes
by David R. Conrad 29 Aug '01

29 Aug '01

James, At 11:44 AM 8/29/2001 +1000, James Spenceley wrote: >Checking each prefix sounds like an awful lot of work, much better to >bitbucket a entire countries prefixes if they collectively don't account for >0.nnn% of your traffic. Except that prefixes aren't allocated by country. Prefixes are allocated to ISPs (mostly). Rgds, -drc

1 0

RE: multi-homing fixed -- not!
by Roeland Meyer 29 Aug '01

29 Aug '01

A business, using between /24 and /19 (exposure of /20's is uncertain. sometimes ... sometimes not), still can't multi-home. Therfore, not fixed. |> From: Randy Bush [mailto:randy@psg.com] |> Sent: Tuesday, August 28, 2001 6:34 PM |> |> > how many providers have multiple POP's in a city that are |> _completely |> > redundant_? That is, they can operate _fully_ with one POP out of |> > service? |> |> none can operate *fully*, as a customer access line pretty |> much has to |> terminate in a single router which can, and eventually will, fail. |> |> but, most large providers have more than one pop in the |> largest cities, |> bay area, nyc, dee cee, etc. and those pops are redundantly |> and diversely |> wired. if not, don't buy from them. life can be simple. |> |> of course, in toledo, you're probably sol. Even big guys, in certain areas, are sol. thx for the proof.

1 0

Re: DNS Parser
by smoot＠tic.com 29 Aug '01

29 Aug '01

> "Deepak Jain" <deepak(a)ai.net> said: > Since IP allocations have been such a hot topic lately, I thought I'd ask > this -- > > Does anyone know of a simple script that will go through a list of BIND > primary files, or more and output a list of output like this: You might find my package "updatehosts" useful. It manages the DNS as a set of flat files (e.g. relationally normalized). It manages reverse zones automatically. Included are some tools to convert the zone files into the flat file format. It is GPLed and available at: ftp://ftp.tic.com/pub/updatehosts -- Smoot Carl-Mitchell Consultant

1 0

RE: What is the limit? (was RE: multi-homing fixes)
by Martin, Christian 29 Aug '01

29 Aug '01

> I don't think filtering on RIR allocations has anything to do > with keeping the > small people down. It is not a political problem, it is a > technology problem. Indirectly it certainly does. It is the small people who cannot justify the host requirements to acquire an allocation from the RIRs. Because the small provider cannot acquire PI space, they must resort to route leaking of PA space to the non-assigning upstream, who in turn must then announce this PA-microallocation to its peers. And, because, like it or not, the facts show that large (forgive the coinage) tier-1s are doing very passive filtering at the peering points, we see this explosion. It is quite enlightening to see what the big-8 exchange between each other. This is where the unobstructed growth is most dangerously occuring. And please don't tell me that we should force the smaller ASN to co-lo or multihome to the same provider of whatever. Any business that allows their suppliers to drive their business requirements when better alternative solutions exist shouldn't be in business. Coming from someone who has on occasion, introduced superfluous information into the GRS, there are limitations to BGP that force such leakage. And it is not a multihoming issue, but a traffic engineering one. Geoff has addressed this problem in his work on multihoming, but this thread is addressing only the multihoming-for-redundancy issue. This is half the problem, and as suggested, is dependent on the RIR allocation policy. What is also occuring (again, in a more dangerous sense) is the intentional leakage of more specific routing information by the mid-size regional ISP for the purposes of multi-provider TE. downstream A has met the requirements for an RIR allocation. It purchases one OC-12 at rock-bottom pricing from NSPA. It then purchases and OC-3 for backup to NSPB, but at a higher cost. If NSPA and NSPB are mutually well-connected at the same level in the AS hierarchy, then there will be an inbound load-distribution problem. So, the ISP breaks the /19 into 32 /24s, and announces them to both providers, depreferencing 6 of them toward the OC-12 carrier using communities. This forces all traffic to flow exactly toward the NSP with the best preference for the route if 1) the /24s are leaked between NSPA and B, and 2) the providers prefer customer routes over peer routes over customer backup routes (which nearly all providers do.). Furthermore, all peer ASNs of NSPA and B and their customers follow a non-deterministic path, that can only be affected if the above requirements are again met. However, there is no method at the ISPs disposal to scope these announcements to only these two NSPs (as the superfluous information does not need to flow beyond them, only the aggregate.) The idr-wg has been working on a mechanism to scope this longer-prefix leakage to the NSPs involved in this type of multihoming. It is actually derived from the dist-list-exclude and dist-list-include path attributes in IDRP (see sections 7.12.5-6 of ISO 10747 for more info). What this would allow a downstream to do is responsibly leak information only to those providers that are being paid to accept it. Isn't that novel? Instead of oppressing our smaller brethren, lets empower them to contribute to the solution. Attempting to squash them hasn't resolved anything, as we all seem to be well aware. Talk to your vendors - encourage them to implement draft-bonaventure-bgp-redistribution-01.txt as it matures. Now if we can only get the providers to upgrade their software... Regards, chris > > It will ultimately be solved when core routers can handle an > Internet worth of > /32's > and an EGP is developed to efficiently propogate changes > (perhaps an open > central > registry with policy applied locally). One has to wonder why > vendors don't > satisfy the > first requirement today. > > Until that time, you can either satisfy the (fairly > reasonable) minimum > allocation requirements, > Implement any number of alternate kludges that have been > proposed, or go home. > > KL >

1 0