- NANOG - lists.nanog.org

Re: multi-homing
by Eliot Lear 31 Aug '01

31 Aug '01

Leo, > I don't do the IETF thing, but has any development effort there > tried to make multihoming / mobility a requirement of a new protocol, > and if so why hasn't there been more progress on that front? There are numerous related activities going on in the IETF to address multihoming and mobility. First, there has been a very long standing effort in the mobility front. MOBILE-IP allows one to hold a single IP address, no matter where one is. It works via tunneling to a known point in the topology, where non-participating nodes rendevous. With IPv6 they're attempting to do one better: there are to be no nodes that are not aware of mobility. That way, once the two end points have connected one can send a rebinding message to the other saying, "I'm over here." The benefit is the elimination of triangular routing. As to multihoming, there are two working groups that are specifically looking at multihoming and its implications. The first is PTOMAIN (don't ask me to expand it. Randy came up with it). PTOMAIN is focused on improving things now through incremental changes to BGP. One of the approaches they're looking at is the scoping of routing updates to a limited number of ASes, after which they would be aggregated into a shorter prefix. MULTI6 is looking at the problem for IPv6. And in this working group things are going a bit slower, but the constraints are looser, since the deployment at this point is, well, limited. There is at least one proposal that talks about NATting and NAT mapping between the end points and within the network. Imagine the edges NATting an address and then unNATing it at an exit. It beats normal NAT in as much as the IP address that the destination sees is the one that the sender used. How it selects addresses, transmits the mapping, and all that are in a draft document. Of course, this stuff is very immature. Our friend Sean Doran is one of the chairs. Perhaps he can comment more. Finally, there are several efforts going on outside of the IETF that may well have very broad implications for both mobility and multihoming. These are research activities of the IRTF. One is the Routing Research Group (RRG), where they're looking at next generation routing. Another effort is the Name Space Research Group, headed by Steve Crocker, Steve Bellovin, and myself. That effort was asked the question "should there be an additional name space above layer 3?" The answer is hard to find, but we are producing an RFC that should be due out in a few months. Finally, there are some more vaguely related things going on. One is SCTP, which is done. It allows for multiple ip addresses per transport end point (as opposed to a single one with TCP). An extension is being considered to allow for addition of transport addresses in the middle of the connection (right now you have to name them all during setup). And finally there is a new working group called HIP (host identiy payload) being run by Bob Moskowitz (see draft-moskowitz-hip-*). Here the idea is to insert a naming layer just as we discussed in the NSRG. Bob has some interesting applications to improve security. There are also mobility possibilities here too. This stuff is fairly early on. Hope this helps, Eliot Lear

1 0

Re: What is the limit? (was RE: multi-homing fixes)
by Larry Sheldon 31 Aug '01

31 Aug '01

> You're not the first to tell that i'm talking nonsense; but i had both > experience with a water-cooled computer (not something i wish to repeat), > _and_ designing hardware for COs (heck, the first computer i laid my hands > on was using thyratrones (sp?) for triggers, and quite a few relays). Well, I really don't want to play "Can You Top This?" (The name of a national radio program when I was a child), but the first computers of my experience were mechanical analog machines--all gears and cams and such. I think the word is thyratrons. > Not everything which works in one-of-a-kind supercomputers is workable in > your average central office. People who build equipment which has to work > for years w/o interruptions, survive quakes, power faliures and > thick-fingered technicans are not idiots; and if water cooling was a real > solution for CO environmental control woes, they'd use it. UNIVAC 1100/90's and IBM 3090 K's (I am not sure of the IBM nomenclature, I never actually worked on one) were hardly one-of-a-kind--there were three or four 90's and at least a couple of the IBM machines in Hayward (look up that place name in a fault catalogue) and Concord. The Bell System probably had 50 or more /90's at the peak (how many 4A crossbar's did they have?) > In an average CO a poodle on a floor has a risk of not being noticed for > a couple of months. It doesn't have an alarm relay, you see? That would be pretty silly--I have not worked in a CO environment for a lot of years, but I can't imagine one without such alarms. > (Have you ever seen a blast of H2/O2 mix resulting from electrolysis? No?) All of the water cooled computers of my experience have the water inside plastic plumbing. Unless somebody leaves the plug out of the bottom of a tank. And by the way, the CO's around here seem to get flooded some--tornadoes rip the roof off, the Missouri disagrees with the Corps of Engineers, or a bunch of elm tree leaves plug up a street drain. The point here is not that liquid cooling electronics is the best, cheapest, or even very good. The point is, the technology exists, and ut works. That it is more expensive than air-cooling is pretty obvious. But I think the facts are that the reason large-scale electronics are not liquid-cooled is that in the late 1980's there were breakthrough changes in electronics designs that greatly reduce the amount of heat produced per some useful unit of measure. If things continue as they are and absent another breakthrough change I think we will be back to where, in order to do what we want to do, we will again have to use liquid-cooling. And it will be an unfortunate expense, but it will work, and it will allow us to do what we want to do. My last on the subject.

4 3

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

31 Aug '01

| Sure, if the supernet & more specifics update atomically No, the supernet "stands in for" the more specifics. Maybe it's more clear if I write: "carrier" x.x.x.x/n [bitmap no-use propagate] "inside" x.x.x.x/n+i [no-bitmap use no-propagate] ... "inside" x.x.x.x/n+i [no-bitmap use no-propagate] Yes? | you get | a processing gain as well as a space / b/w gain, as you process a | set of identical NLRI's in one shot No, the question here is, are there savings compared to receiving a _real_ x.x.x.x/n [no-bitmap use propagate as-set] plus probably a bunch of x.x.x.x/n+i [no-bitmap use propagate no-as-set] more specifics from other directions? Or alternatively, just the more specifics themselves? Now - there are interesting behaviours due to the selection of a single "carrier" x.x.x.x/n -- unless you use the AGGREGATOR tag (setting it to yourself), you have a major problem to deal with: there are now a bunch of more specifics with DIFFERENT attributes covered by x.x.x.x/n, since you are hearing different flavours of x.x.x.x/n (with different bitmaps and different attributes). What now? Thus, you either not aggregate at all (thus the thrown away "carriers" are just on-the-wire compressed format), or you try to construct a new set of attributes which is correct. Tricky! Also computationally expensive. |(and heh, processing a | route flap of ^701$ in one shot, can't be a bad thing, If ^701$ can form a guaranteed accurate bitmap then it can also generate an atomic aggregate and let the more specifics leak around the rest of the world (and even if necessary through itself). The bitmap buys very little here, other than an indication of which more specifics MIGHT be expected to leak through. (It also doesn't work for the case where you have disjoint sets of addresses originating in 701 itself.) You got it right in this paragraph: | However, I had rather assumed the point of these so-called TE | more-specifics (where there are some) is that they don't all | update atomically. Then you need code to split them out and | put them back together again, and though you are doing better | on bandwidth for the updates (which is not a problem anyway) | you are doing worse on space & processor power. Yup. | I may be missing something. Well, I was saying "I may be missing something" earlier, but I guess I didn't miss anything after all... Sean.

1 0

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

31 Aug '01

Alex Bligh <alex(a)alex.org.uk> writes: | The trouble with using 1 bit to represent 1 prefix is that there is | a need to move more than 1 bit of information per route between | AS's (think AS paths for loop detection, communities etc.). The bit in question when set means "a subnet which has attributes identical to the parent prefix, with the exception of the bitmap attribute colouring that parent prefix". In other words, x.x.x.x/19 [level 24, 111100001010] [other attributes] means x.x.0.0/24 [other attributes] x.x.1.0/24 [other attributes] x.x.2.0/24 [other attributes] x.x.3.x/24 [other attributes] x.x.8.x/24 [other attributes] x.x.9.x/24 [other attributes] x.x.11.x/24[other attributes] x.x.13.x/24[other attributes] plus do not install x.x.x.x/19 See what I mean by it being a compression system for more specifics? Sean. P.S.: thank you for making the iBGP and mpBGP points so clearly, too

2 1

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

31 Aug '01

On Thu, 30 August 2001, Patrick Greenwell wrote: > > I don't know what the goal of "basement dual-homers" is. I think that > > is the other thread, which I haven't been keeping up with. > > My point was simply that the "basement dual-homers" probably want the same > thing as the "people that matter", which is disparate paths to the > Internet. Maybe Bill Gates' or C. Michael Armstrong's homes have dual-entrance cable vaults, but I suspect most basement dual-homers don't have disparate paths to the Internet nor or really looking for that level of reliability. How many people choose a second voice long distance company for their homes? So what do basement dual-homers really want? Most folks seem to be trying to protect themselves from the business practices of their provider, not necessarily the physical problems. Are we solving the wrong problem precisely? > Except for the small problem that there is no guarantee that DNS servers > will honor TTLs, that this solution would necessitate dialing down > TTLs to the lowest possible value to maximize effectiveness which would > greatly increase DNS-related traffic, and flapping could be really ugly. > > DNS in lieu of a routing protocol make me uncomfortable. Necessity is the mother of invention. Problems are rarely solved before there is critical need to solve them. Should we be trying to use IP addresses as permanent identifies, or names? If it became a critical issue, would programmers start/best practice using the second, third, etc IP address returned in the DNS query? If a SYN fails, should the IP stack flush the DNS cache entry and check for a fresh IP address? I agree, using DNS in lieu of routing makes me uncomfortable. However, we also need to remember the reliable "service" we are creating is really at Layer 8. There may be a need for some smarter middle-ware (I hate that term) which spackles over some of the bumps and gaps. IP emulates a reliable network over an unreliable infrastructure. Do we also need an App/IP layerto emulate reliable services over an unreliable IP network? I would rather add a new floor on top, than trying to jack up the foundation and change the basement.

7 7

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

31 Aug '01

|> From: mike harrison [mailto:meuon@highertech.net] |> Sent: Thursday, August 30, 2001 6:29 AM |> Maybe it's time to make some small point cooling systems for routers. |> When I was young electronics nut, we'd cool stereo amps this way |> to up the power output. As the last rack mount computer I installed |> had 6 cooling fans.. maybe it's time... see "Pelletier Effect" devices. Thermos made a portable ice-box, using that tech, for a while. It's all solid-state, no moving parts.

4 3

RE: FIBER CUT: Dallas to West Coast
by Chris Boyd 31 Aug '01

31 Aug '01

If you really need diversity, talk to _one_ carrier that can go everywhere you need. It's much easier for one proviioning group to make sure that your circuits don't go through the same fiber, ring, cross-connect, mux, or office if they have complete visibility to both circuits. Nigh impossible if you try to get two different carriers to cooperate like that, I would think. For better or worse, many times carriers wind up putting fiber right next to the competition. One tugboat crash, derailment that spills acid, backhoe, etc can take out all the routes for all the carriers. --Chris > -----Original Message----- > From: Greg Pendergrass [SMTP:greg@band-x.com] > Sent: Thursday, August 30, 2001 2:14 PM > To: Brian; nanog(a)merit.edu > Subject: RE: FIBER CUT: Dallas to West Coast > > > You always have to specify to the carrier that you want diversity. For > longhaul, sometimes even big name providers will subcontract to another > provider. For instance, you may get 1 OC-3 from MCI and another from > Sprint, > but both might be going through the same Qwest OC-192 from Denver to San > Jose. I've seen it happen and it's always ugly for the buyer when someone > backhoes it. You have to specify and sometimes pay more to be certain of > your diversity. > > Greg >

2 1

Re: First it was backhoes, then flaming trains, and now...both?
by Marshall Eubanks 31 Aug '01

31 Aug '01

> > > I found this simply too funny: > > "MULVANE, Kan. (AP) - A freight train carrying hazardous materials caught >fire Thursday after it hit a backhoe apparently parked on the tracks by vandals." >-snip- > > --msa > > It would have been ironic if the accident had severed a major fiber conduit. Regards Marshall Eubanks

2 1

First it was backhoes, then flaming trains, and now...both? (fwd)
by Larry Sheldon 31 Aug '01

31 Aug '01

> I found this simply too funny: > > "MULVANE, Kan. (AP) - A freight train carrying hazardous materials caught > fire Thursday after it hit a backhoe apparently parked on the tracks by vandals." > -snip- > > --msa I wonder how funny the engine crew, fire-fighters, and HAZMAT folk thought it was.

1 0

First it was backhoes, then flaming trains, and now...both?
by Majdi S. Abbas 31 Aug '01

31 Aug '01

I found this simply too funny: "MULVANE, Kan. (AP) - A freight train carrying hazardous materials caught fire Thursday after it hit a backhoe apparently parked on the tracks by vandals." -snip- --msa

1 0