- Test - lists.nanog.org

RE: Is anyone using GILAT's "Spacenet" service
by Rowland, Alan D 01 Sep '01

01 Sep '01

The data has to bounce off the satellite 22,600 miles up, a not trivial distance ( ~1000-2000). Course they could lower that to ~500-1000 if they cache on the sat. :) -Al -----Original Message----- From: Dennis Dayman [mailto:dennis@thenose.net] Sent: Thursday, August 23, 2001 3:05 PM To: nanog(a)merit.edu Subject: RE: Is anyone using GILAT's "Spacenet" service > 500ms RTT which I do not believe. Try more like 500-2000 I've been on both Telstar 7 and GE satellites in their network and it's bad. NOC/CS is a pain to work with. Major problem though. Not only do you have to deal with RAIN fade at your locations, but they only have one uplink facility and when they get "covered" everyone in the network is dead. They have no back-up's. You have to RPA/HPA (proxy) all your HTML traffic and E-Mail, FTP, TELNET are VERY SLOW since it doesn't use their HTML proxy. --------------------------- Dennis Dayman dennis(a)thenose.net Voice 972-772-7890 FAX 972-772-3337 ------------------------------------------------------------------------ ------ What goes up, must come down. Ask any system administrator. ------------------------------------------------------------------------ ------

2 1

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

01 Sep '01

I have been trying to avoid saying this, but this is just nonsense with a little srinkle of "doesn't matter" here and there. > Actually, talking about water/electricity interaction in refrigerators, > lab equipment, etc, misses the very simple point - a probability of a leak > is proportional (as a good approximation :) to the number of moveable > components (PCBs, connectors, etc) in the system. In a typical CO it's > tens or hundreds of thousands. I don't remember seeing anybody talking about lab equipment and refrigerators here. We (some of us) were talking about liquid-cooled electronics, some of them were talking about actual experience--mine with water-cooled CPU's. > PS. Water is not a good coolant, and even distilled and deionized > water tends to pick ions from metal parts rather quickly. Spirits > are flammable; CFCs are bad for environment. There's also an > issue of toxicity. Water is one of the better coolants--particularly when cost is considered. The rest of that is one of the sprinkles I mentioned--water can in fact be toxic, see http://www.dhmo.org/ In the real, actual world, the coolant is in its own circulation system (like houses, engines, and such), so cruft in the water is no more than a maintenance issue every some large number of hours. > Of course, everything is doable, but what is the cost? > Off-the-shelf components are all designed for air cooling. > Switching to liquid cooling means a lot of custom stuff; which is > expensive and which takes a long time to design and manufacture. As I recall the electronic components in a water cooled 1100/90 CPU were as "off-the-shelf" as anything else in the machine, including most of the water system. No more "custom stuff" any "branded" equipment, I'd say. > PPS It is not voltage which matters, it's current :) Even if leaks do > not cause shorts the moisture accumulation may corrode parts > leading to mechanical shorts, it also may cause excessive > cross-talk. Sporadically malfunctioning equipment is much worse > than flat-out burned out. Not sure what this all means. Yes, we did have failures due to water leaks. Idjits on the floor above us neglected to put the plun in the bottom of their water tanks and pour a lot of water on us! > PPS Finally, getting your hands wet makes your changes to get killed > by electricity _much_ higher. 48V won't do you any harm if your > hands are dry, it may kill if they're wet. Als true--but then we were always careful to dry our hands before leaving the restroom. And checking the folks upstairs if we saw water bottles on the dock.

5 4

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

31 Aug '01

| Assigning a prefix to a continent wouldn't be a good idea, because | that way every regional ISP has to Well, that's what's been happening for a few years now... But consider this: | announce the very large bitmap for the entire continent, while most of it | contains just zeros. Per metro area would be better. But two ISPs that | have many multi-homing customers in common could use a prefix for just the | two of them, regardless of geography. Instead of a bit-vector with lots of zeros, do run-length encoding of the bits you don't have, or the bits you do have. Now compare that to doing automatic aggregation, so that instead of 16 contiguous 1 bits you introduce a prefix of x.x.x.x/(n-4). See what I mean by your bit-vector just being another representation (possibly more efficient on the wire) of what's already there? That is, you are noticing that for any given abstraction boundary that is non-topological, exception routes (more specifics or described with your bit-vector) have to be introduced when a black hole would otherwise result, and may be desirable to optimize routing. This is why the RIRs' prefixes are announced as relatively long chunks of /20s or so rather than the /8s or shorter as they are gotten from IANA/ICANN/ASO/thin air/whatever. If you try to take the same approach and have a "SRIR" (s = sub), you will see a carving up of the prefixes over time, in the same fashion. The ONLY way to avoid this right now is to have addressing exactly match topology. The problem here of course is that nobody will agree on which N entities are "top level". | I'm mostly trying to solve the memory problem, but it should also help | with (but certaintly not completely solve) the processing problem. It doesn't really do either. You have made a few time-vs-space tradeoffs which move the problems around a bit, but don't actually eliminate them. | Since an updated bitmap is always the same size and it updates many routes | at a time, it should take less CPU power to process the updates. Parsing the received updates is not the major worry, and your fix is targetted on the syntax of the updates, rather than their semantics, which is where the problem lies. | I think the only way to really know what the processing benefits of all of | this are is implementing it, or run detailed simulations, but those | require pretty much an implementation as well. Well, I won't stop you from testing an implementation or two. Write back to the list (or better yet, the IDR list) when you're done. Let me take some of your text out of context and agree with it fully: [A permanently stable holes-in-CIDR-blocks environment exists] | Only if there is a limit on the number of ISPs. I don't think there | is such a [practical rather than absolute] limit The problem with metro-based addressing is that the statement above is equally true for it as for PA addressing. Sean.

2 1

RE: Cisco and Juniper Inter-Operability Issues ???
by Stanley, Jon 31 Aug '01

31 Aug '01

To clarify on the last point: "commit confirmed <number>" specifies the number of miniutes that can pass without another commit before the changes will be automatically rolled back. I use this ALL the time on firewall policies (something like commit confirmed 2 to verify that I'm accomplishing what I want to). It really is a lifesaver. -----Original Message----- From: John Kristoff [mailto:jtk@depaul.edu] Sent: Friday, August 31, 2001 3:59 PM To: nanog(a)merit.edu Subject: Re: Cisco and Juniper Inter-Operability Issues ??? Devon True wrote: > Any gotchas we should watch out for and any tips/tricks? I read the > NANOG archive and saw someone mention OSPF problems with Juniper and to > run ISIS. Is that still the case? I haven't seen any OSPF compatibility problems, including the use of authentication and changes in the default reference-bandwidth between Junipers and Cisco. Tested using JunOS 4.4 and 4.3. As far as the OC3c goes, You may want to preconfigure all the VPIs you'll ever have in advance if you can. Anytime you reconfigure them, the Juniper does a reset of the SAR to reallocate memory to the VPIs. This will cause all your ATM circuits on that interface to bounce. If you setup your peers under a BGP group statement, you will also need a 'peer-as' statement at the group level. You can give it a bogus/private one there just to satisfy the config. I don't think they have fixed this wasn't fixed as of JunOS 4.4. And finally, 'commit confirmed' is your friend. :-) John

1 0

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