- Test - lists.nanog.org

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

29 Aug '01

<quote> Multihoming is popular because the cost of transmission circuits is plummeting, making it less expensive to buy Internet access services from two or more ISPs. At the same time, companies are more concerned about the reliability of their networks and less willing to trust one service provider. </quote> This gal only has it half right. It isn't the reduced cost of circuits, it's it's the uncertainty that that circuit's provider will still be in business next month, or that a change in that provider's business plans, or M&A activity, will make them abandon that circuit altogether. This coupled with 2+ month provisioning schedules. A dropped circuit will result in a 2+ month business outage. A 2 week business outage will put most companies out of business for good. How many, of Northpoint's 100K customers survived Northpoint's business failure? How many, of those that did, were multi-homed? How many of them are multi-homed now? <quote> "Half of the companies that are multihomed should have gotten better service from their providers," says Patrik Faltstrom, a Cisco engineer and co-chair of the IETF's Applications Area. "ISPs haven't done a good enough job explaining to their customers that they don't need to multihome." </quote> Is Patrik Faltstrom still an IETF co-chair? Is he still helping the [failing] credibility of the IETF? Maybe, that's why? How can any ISP, or anyone else, credibly guarantee that they'll still be in business next year? Or, that they wont sell out to the very rich bad guys? Or, that circuit provisioning will drop to under 5 calendar days? Because, that is the *only* way you will convince business customers that they don't need to multi-home. At $99US for 512MB of PC133 RAM (the point is, RAM is disgustingly cheap and getting cheaper), more RAM in the routers is a quick answer. Router clusters are another answer, and faster CPUs are yet another. All of the above, should get us by until we get a better router architecture. If the IETF is being at all effective, that should start now and finish sometime next year, so that we can start the 5-year technology roll-out cycle. The next time that PF goes out in public, he should either have his lips perma-bonded together, or have the lower part of his face covered in duct tape. Maybe then, he can resist the urge to chew on his feet. |> -----Original Message----- |> From: Irwin Lazar [mailto:ILazar@tbg.com] |> Sent: Thursday, August 23, 2001 2:35 PM |> To: 'nanog(a)merit.edu' |> Subject: multi-homing fixes |> |> |> |> A while back there was an article in Network World on |> problems due to the |> rise of multihoming: |> http://www.nwfusion.com/news/2001/0402routing.html which was |> discussed in |> great length in this forum. |> |> Has the IETF created a working group to deal with a |> long-term fix for this |> issue, and if so, is there a URL for its activities?

28 54

RE: multi-homing fixed
by Larry Sheldon 29 Aug '01

29 Aug '01

> On Tue, 28 Aug 2001, Randy Bush wrote: > > > > > the point of 2xDS3 was specifically to get major services, and not to get > > every basement dual-homer. > > Please explain why the "basement dual-homer" should not have the same > right to diversity as the "major services." > > And please, be specific. That is easy. She is not: One of the old crowd. One of the power elite. She is probably: Trying to provide a service, which if successful would threaten the sit-on- their-ass crowd. Too young to have been around when what matters happened--the gathering up of tons of address-space at no cost to the gatherers.

16 19

FIBER CUT: Dallas to West Coast
by Sean Donelan 29 Aug '01

29 Aug '01

Is anyone else seeing a fiber cut between Dallas and San Diego/Los Angeles?

1 0

RE: What is the limit? (was RE: multi-homing fixes)
by Roeland Meyer 29 Aug '01

29 Aug '01

|> From: alex(a)yuriev.com [mailto:alex@yuriev.com] |> Sent: Wednesday, August 29, 2001 10:40 AM |> |> > |> > To boost this point, exponential growth, approaching |> > |> infinity, becomes |> > |> > asymptotic. |> > |> |> > |> The only asymptote of an exponential curve is it's |> asymptote towards |> > |> the X axis, for as X approaches negative infinity. |> > |> > The point remains that it is nonsensical, given a finite |> universe. The curve |> > doesn't fit observable reality. |> |> This is math. Observable reality is irrelevant. ROTFLMAO! However, let me re-state that the curve doesn't even fit probable reality.

1 0

RE: What is the limit? (was RE: multi-homing fixes)
by Roeland Meyer 29 Aug '01

29 Aug '01

|> From: Alex Bligh [mailto:alex@alex.org.uk] |> Sent: Wednesday, August 29, 2001 11:20 AM |> |> --On Wednesday, 29 August, 2001 10:25 AM -0700 Roeland Meyer |> <rmeyer(a)mhsc.com> wrote: |> |> > To boost this point, exponential growth, approaching |> infinity, becomes |> > asymptotic. |> |> The only asymptote of an exponential curve is it's asymptote towards |> the X axis, for as X approaches negative infinity. The point remains that it is nonsensical, given a finite universe. The curve doesn't fit observable reality.

4 3

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

29 Aug '01

As much as arguing with Sean is generally a lost cause (face it folks, he knows his sh*t), I would like to comment on the disasters he presents and offer a reason why this was so, from someone who wasn't there. Sometimes an outside view is a clearer one. > The Internet *FAILED* in 1994. The number of prefixes > carried globally > exceeded the ability of the global routing system to carry it, and > as a result, some parts of the world deliberately summarized away > whole large-scale ISPs merely to survive. > The Internet *FAILED* again in 1996, when the dynamicism in > the global routing system exceeded the ability of many border > routers to handle, and as a result, some networks (not just core ones) > deliberately made the Internet less quick to adjust to changes in > topology. > > Thus, the routing system FAILED twice: once because of memory, once > because of processor power. And both times because the routers themselves were not designed exclusively for the Internet and its requirements. In 1994, the Internet was running on AGS+ and 4000 boxen. Compare these boxes, 7 years later (or 3.5 Moore cycles later) to a 124xx, or an M160, or a TSR or any other vendors new gear. Today's systems are 10-20x more memory-rich, (still CPU constrained), and the routing algorithms are adapting to deal with excessive dynamism. Route damping is of huge importance, but this is something that is well known. ORF capabilities in BGP, redistribution communities, etc, will continue keeping updates frequency in check. And again, routers today are generations behind today's Moore cycle. Furthermore, we are still using general purpose CPU's. Imagine a BGP ASIC that could process a zillion updates per second! 8-> The point is that the vendors did a good job of dealing with the speed issue. In 1994, even Sean would have been impressed to see an OC-192c router interface performing at wire speed with 1000 line ACLs in and out, etc, etc. The speed problem has been addressed (the number of OC-192c/STM-64 ports in use is pretty low compared to the number of OC-48s/STM-16 ports that were in use 12 months after the those cards were released), so now the vendors can start working on the global routing system. Then again, most of them are working on MPLS which does nothing to address the GRS. *sigh* (Note to vendor gurus - isn't it interesting how an increasing number of Internet "greybeards" - sorry sean, I don't recall you being all that grey or having a beard for that matter - continue to concern themselves with GRS stability and scaling while at the same time puking on all the MPLS hype?) > If the size or the dynamicism of the global routing system grows > for a sustained period faster than the price/performance curve of > EITHER memory OR processing power, the Internet will FAIL again. <-snip-> > So, Moore's Law, or more specifically the underlying curve > which tracks the growth of useful computational power, is > exactly what we should compare with the global routing system's > growth curve. This is only the case if the algorithmic complexity is a constant. Reducing the algorithmic complexity from O(N^2) to O(N), for example, reduces exponential growth of the data processing requirements to linear growth. Going from O(N) to O(logN) makes the requirements sublinear. An example of this would be the introduction of IS-IS mesh groups. > > Note that when Moore is doing better than the Internet, > it allows for either cheaper supply of dynamic connectivity, > or it allows for the deployment of more complex handling > of the global NLRI. > > The major problem, as you have pointed out, is that processing > requirement is often bursty, such as when everyone is trying > to do a dynamic recovery from a router crash or major line fault. > We could still use 68030s in our core routers, it's just that it'd > take alot longer than it used to perform a global partition repair, > which means your TCP sessions or your patience will probably time out > alot more frequently. Are you kidding! My patience times out during single BGP session failure restoration... ;) > | I think that what we need to do is have a fourth group, > call them Internet > | Engineers for lack of a better word, come in and determine > what the sign > | should read. > > Structures built according to best known engineering practices > still fall down from time to time. That's the problem in anticipating > unforeseen failures. Consider yourself lucky that you haven't had > to experience a multi-day degredation (or complete failure!) of > service due to resource constraints. And that you haven't > run into a sign that says: "please note: if you try to have an > automatic partition repair in the event this path towards {AS SET} > fails, your local routing system will destabilize". Since I wasn't there during your problems in 1994 and 1996, I ask you, "Did you not know that you were approaching a resource constraint?" In regards to memory, we all know that we can triple or even quadruple the size of the table, today, with headroom reamining. The update frequency ceiling is less tractable, due to implementation dependence, but a correlation between table size and update frequency would certainly be of use in approximating it. I think the table size issue is solvable. Processing the table is where we may be hurting, which we are attempting to solve by constraining the update frequency. > | Finally, we have a sixth group, call them the IETF, come in > | and invent a flying car that doesn't need the bridge at all. > > As Randy (with his IETF hat) says: "send code". > I wish I could. But alas, I am too busy counseling my routers, ensuring that they are happy, trying to keep them stable. They are temperamental little b*st*rds, I tell ya. -chris > Sean. >

2 1

Re: What is the limit? (was RE: multi-homing fixes)
by smd＠clock.org 29 Aug '01

29 Aug '01

Leo - Draw two curves, the first y=x/2, the second y=x^2 Move the value of x for y=1 for the first curve left by 2, 5 or 10 and it will still be surpassed by the second curve. You will even see this for a second curve of y=x*2 or y=x. The global routing table size HAS grown exponentially in the past. Rationalize it any way you want, blame whatever you like, but there is no known way to construct a router that can handle that kind of growth in anything but a short term, and the trend for the components in the router growth curve is simply not going to increase to a long term superlinear rate. A 10x system performance boost today just moves the x point for y=1 of fundamental curve claimed by Moore's Law to the left a few notches. Or are you claiming that routing equipment will have a fundamentally different, and larger, growth curve than other computing systems? (I think there is a basis for claiming that there are some reasons which would support a _shallower_ growth curve for routing equipment, actually). In short: are you claiming that the caeteris paribus assumption in comparing Moore's Law to global routing table size is clearly false? It would be nice to see even a partial proof of such a claim. >From anyone. Sean. (today's insult-free posting)

3 2

Re: What is the limit? (was RE: multi-homing fixes)
by smd＠clock.org 29 Aug '01

29 Aug '01

| [big routers] will cope just fine with the current routing table growth. "current" being the key word here. It's not exponential today. (pace hcb) That is, after all, the entire point of this conversation: is current growth "too slow", "too fast" or "just right"? Sean.

2 1

Re: What is the limit? (was RE: multi-homing fixes)
by smd＠clock.org 29 Aug '01

29 Aug '01

| Nonetheless, it's still annoying as hell that Cisco can't just allow a GB | or more of RAM in 5-6 figure router and just be done with that aspect of | it... They used to build boxes with cheap no-ECC, no-parity DRAM and had their fingers blown off by people who started counting the difference between line BER and e2e checksum failures, particularly on faster boards. Now they use well-built ECC SDRAM in general, and retain their fingers. AFAIK they don't forbid anyone from going out and acquiring el-cheapo RAM from other suppliers. A bit-error in a patricia tree can be really yucky. Sean.

1 0

multi-homing
by steve uurtamo 29 Aug '01

29 Aug '01

i) prefix length is unfortunately not directly related to the "need" for multihoming. ii) multihoming costs the person receiving the multihoming an amount of money that is variably determined by their upstream proviers. iii) the number of prefixes that _would_ multihome if they: a) had the appropriate equipment b) had the appropriate tech-brains c) had an ASN d) had connections through multiple providers is _not_ known. if you don't believe i) just imagine a content provider that is really interested in reaching its customers through the most direct and fast path possible, and who can't afford any outages. (their content isn't really worth much during an outage). ii) and iii) are important, taken together. is _your_ router going to explode if my /24 gets added to your table? of course not. your main concern is that your router explodes if _too_ many people's prefixes, of whatever size, get added to your table. this is, i think, a good thing to worry about, but it's a little early to be worrying. if nothing else (and i'm most certainly not arguing that this is the best solution), market pressure can be applied at points ii) and iii) to reduce to an arbitrarily small number the number of prefixes of concern here. all arguments of the variety, "i pass X [MGT]bits/sec, that's why i qualify and you don't" or of the variety "i house a network of size /X and that's why i qualify and you don't" are specious as well. ISP's need to multihome for reasons quite different (well, exactly the same but in an inverted direction) from the reasons that content providers do. it's important to note that prefix length is _not_ always, or perhaps even often, directly related to amount of traffic passed. obligatory attempt at a useful comment: completely ooma(tm) speculation, but i wonder if this would work: (if someone's done this calculation, or can back-of-the-envelope do it, i'd be curious to hear the results): consider the size of an ideally "full" route table for a particular traffic-passing router. consider a) the amount of time it takes for a "maximal" percentage of particular prefixes in that table to actually pass traffic across two of your interfaces and b) acceptable latency across those two interfaces in your router. ("maximal" here means whatever your router's prefix table capacity is, and "full" means the size that we as a community need to be able to support but currently cannot.) it's possible that you can: update a "cache" of prefix entries locally against a slower, but more "expandable" prefix-server. the long and the short of it is, you offload the "live" route table to a slower (read more cheapy expandable) box that has a fast connection to your router(s). when a packet's destination route prefix isn't contained in the cache, the prefix-server is polled (remember, very low latency to this box) for the correct route, and it's added to the table. prefixes not used for awhile age out of the local cache, and prefixes currently in use are checked (through the prefix-server) periodically to determine validity. end-to-end (from far-flung BGP speaking routers) propogation time for route information isn't exactly zippy right now anyway, so it shouldn't bother anyone that "best-path as currently should be known to me" isn't always taken for every packet. so the tradeoff is more clear here -- the "slow" table server could conceivably use very cheap technology for table storage (many GB of RAM on something with a slow CPU, or even perhaps a fast-enough RAID array spring to mind), and the "fast" router only needs to poll at a rate commensurate with acceptable latency. the "slow" box and "fast" box could be independent units inside of a commercial router or not, and the "fast" link between the live table and the cache should be cheap enough. i'm not describing a route server here, really. i'm really talking about offloading the space requirements to something that's slower, and using a local cache to (presumably) keep router table size down. (this external box _would_ be the one responsible for propogating bgp updates to your peers, and inbound bgp updates would be transparently redirected by the router to this box to deal with). s.

3 2