- NANOG - lists.nanog.org

Are You In Debt ?
by flowers100＠uk2.net 16 Jun '00

16 Jun '00

1 0

Re: Summary: Bay Area Power (2000-06-14)
by Steven M. Bellovin 16 Jun '00

16 Jun '00

In message <200006152243.SAA24809(a)montu.connix.com>, gwright(a)thebiz.net writes: > >I was under the impression that these power shortages were the >result of less over-engineering on the part of power companies due >to deregulation but maybe this isn't such a new situation after all? > > There was an interesting article in the May 11 Wall Street Journal about how deregulation has led to this situation. I quote: Deregulation, now under way in 24 states, upsets that structure and allows new players -- some affiliated with utilities, some not -- to build power plants and sell electricity. Prices are set by competitive markets; risks are borne by investors, not ratepayers. At the same time, utilities are surrendering control of long-haul transmission lines to new nonprofit operators whose job it is to ensure fair access to the grid -- the multistate system of high-voltage lines. The result: a national electricity system that is vulnerable to disruptions caused by equipment breakdowns and human error as newly established regional grid operators assume responsibility for much larger areas than those formerly overseen by individual local utilities. For big energy users, who expected deregulation to bring lower prices, not lower reliability, it has been a worrisome experience. Briefly, established power companies were worried that decreasing prices would prevent them from earning money on their investment; new players held off until they could figure out what markets would be most profitable. The transmission system is in bad shape, too -- San Francisco is specifically identified as having poor connections to the larger power grid. There's a lot more in the article, including notes about how incomplete deregulation has contributed. If you subscribe, you can find it at http://interactive.wsj.com/archive/retrieve.cgi?id=SB957998459784551619.djm

1 0

Re: Summary: Bay Area Power (2000-06-14)
by Sean Donelan 15 Jun '00

15 Jun '00

Large power consumers can sign an interrupt able contract with a (deregulation) power company. Interruptible agreements give a discount in exchange for the promise the customer will voluntarily curtail their usage when asked. If they don't, they get socked with penalties. These agreements have existed for decades. On Thursday, PG&E asked its interruptible customers once again to curtail their usage. Involuntary curtailment is different. The prediction is involuntary curtailments and interruptions will become more commonplace as the market adjusts to deregulation. Hopefully, once deregulation is sorted out the proper incentives will exist to construct additional transmission and generation facilities. Some electrical customers disconnect from the grid anytime a potential exists for an unscheduled interruption. For example, some sensitive facilities switch to internal power anytime lightning strikes within five miles. They believe their internal power systems are better (albeit more expensive to operate) than the utility power. There is a different school of thought which believes transferring to an alternate power source is risky in and of itself, so its better to stay with the utility until it fails, because the utility may not fail but the transfer could. Finally, if you speak with the right people at the Edison Institute, they are very frank, there is always the potential for an unscheduled power interruption. Anyone who absolutely, positively can not risk any chance of an interruption should have an independent, standby power source. On Thu, 15 June 2000, gwright(a)thebiz.net wrote: > lucifer(a)lightbearer.com writes: > > At least one major data center disconnected from the grid and went to > > generator power, prior to the rolling blackouts. The motivation was not > > stated, but it seems likely that they were requested to do so as part of > > the voluntary interruption efforts. No interruption of service was seen. > > In a conversation with an MFS engineer today I mentioned the problems > in the Bay area. He previously worked for SNET (Southern New > England Telephone, now part of SBC) for many years and said it was > standard practice for them to disconnect COs from the grid and run > off generator power for hours or even a day or two during the > summer season. > > I was under the impression that these power shortages were the > result of less over-engineering on the part of power companies due > to deregulation but maybe this isn't such a new situation after all?

1 0

Re: Summary: Bay Area Power (2000-06-14)
by Danny McPherson 15 Jun '00

15 Jun '00

I believe they're more so the result of "brown outs" as the power companies attempt to "proactively" deal with extremely high loads. Given your message, I guess it does make sense for the power companies to first inconvenience business customers that 1) use a substantial amount of resources and 2) already have alternative method of supporting themselves. Of course, I'd guess there's considerable ground for objection to this model. -danny > In a conversation with an MFS engineer today I mentioned the problems > in the Bay area. He previously worked for SNET (Southern New > England Telephone, now part of SBC) for many years and said it was > standard practice for them to disconnect COs from the grid and run > off generator power for hours or even a day or two during the > summer season. > > I was under the impression that these power shortages were the > result of less over-engineering on the part of power companies due > to deregulation but maybe this isn't such a new situation after all? >

1 0

IGP Survey
by Danny McPherson 15 Jun '00

15 Jun '00

Could anyone that's every "deployed" an IGP take just a second to answer the following questions? Please reply in private, I'll send a summary to the list. Thanks in advance! -danny [snip] Included below are several questions regarding IGP use. If you don't have the time to complete the entire questionaire, answering the first three questions would still be of great benefit. Not answering specific question(s) is also fine (as you may have guessed). The information collected will be made generally available once complete. 1. Company Name (please provide so that multiple response for a single network are appropriately accounted for): 2. Do you wish to keep the company name confidential? 3. What IGP did you select: 1) OSPF 2) IS-IS 3) RIP 4) RIPv2 5) IGRP 6) EIGRP 7) Static 8) Other (please list) 3. Why did you select this IGP (list all that apply, in order of precedence)? 1) Scalability 2) Stability 3) Robustness 4) Vendor Support 5) Familiarity 6) Existing Deployment Base 7) Historical Reasons 8) Feature Set (i.e. Traffic Engineering) 9) Other (please list) 4. If you run a LS protocol, do you run the network (complete AS, or backbone) as a single area, or do you use multiple areas? 5. In case of OSPF, do you use stub, non-stub or NSSA? 6. In case of IS-IS, one level or multiple levels? 7. What do you believe is the primary advantage of this IGP? 8. What do you believe is the primary disadvantage of this IGP? 9. What notable features of the protocol do you use (i.e. OSPF NSSA)? 10. If applicable, what routes do you carry in your IGP in relation to BGP (i.e. customer and internal, internal only, etc..)? 11. How may prefixes do you carry in your IGP? 12. Do you use (or plan to use) your IGP for MPLS traffic engineering? 12a. If not, any particular reason why? 13. Do you use one IGP or multiple IGPs? 13a. As a result of: 1) Having two historical networks, and "redistribute" between them? 2) or maybe every BGP confederation sub-AS runs their own IGP? 3) one IGP (linkstate ?) in the middle, and another (RIP?) at the edges? 4) maybe overlap IGPs 5) maybe one IGP per continent (US vs Europe vs Asia) 6) Other (please list) 14. Do you tweak the protocol's configuration (like changing default timers)? 14a. What values do you feel need the most attention? 15. If you could change/enhance anything with this IGP what would it be? 16. How may routers were in the routing domain? 16. Do you have any additional comments you'd like to share?

1 0

Re: San Francisco power outages imminent
by Jason Legate 15 Jun '00

15 Jun '00

We spoke with SVP, and they said that they are performing rolling 2 hour blackouts in "grid sections". They are on the Bellevue section right now they said. On Wed, Jun 14, 2000 at 04:25:30PM -0700, Pete Bowden wrote: > There was apparently a momentary outage in Santa Clara (less than 5 minutes) > at my home, and there was a large area of Santa Clara (around Lafayette, > El Camino Real to the West of the Santa Clara University) which had a power > outage... I'm not sure the duration, or if it is still out. Santa Clara > has its own power company (Silicon Valley Power, owned by the City) but they > participate in the California Independent System Operator of power system > so they too will likely be impacted. -- /--------------------------/ Jason Legate \------------------------\ | jlegate(a)sitesmith.com | SiteSmith, Inc. | | 24x7 Call Center | http://www.sitesmith.com | | 888.898.7667 | PGP Key ID - 0xA855AAC3 | +---------------------------------+--------------------------------+ | Fingerprint - 2D5F 87A0 26E6 A65B 6837 D100 FB54 A972 A855 AAC3 | \------------------------------------------------------------------/

10 13

Re: in-addr.arpa?
by Vadim Antonov 15 Jun '00

15 Jun '00

Hank Nussbacher <hank(a)att.net.il> wrote: > Why would 216.136.44.104 do something like this? Aside from DNS glitch this traceroute has other funnies: > 10 sl-inetconn-1-0-0-T3.sprintlink.net (144.228.207.46) [AS 1239] 200 msec 204 msec 208 msec > 11 pa1-atm0-6-bbr01.alby.twtelecom.net (207.250.101.2) [AS 4323] 244 msec 264 msec 248 msec > 12 pa1-atm0-5-acr01.alby.twtelecom.net (216.136.44.242) [AS 4323] 256 msec 252 msec 252 msec > 13 learnl-ppp-1130-09-u242.alby.twtelecom.net (207.250.24.30) [AS 3857] 256 msec 260 msec 256 msec > 14 ip104.44.136.216.in-addr.arpa (216.136.44.104) [AS 4323] 404 msec 400 msec 380 msec Look at the ASNs, particluarly hops 12-13-14 :) --vadim

2 1

RE: PMTU-D: remember, your load balancer is broken
by rdobbins＠netmore.net 15 Jun '00

15 Jun '00

The 576 value of the MS PPP MTU is merely a default - it can be changed with a registry hack. Yes, fragmentation has indeed become a Great Evil due to the large amounts of data we're pushing, and the time/resources required for fragmentation/defragmentation. Forcing excessive fragmentation/defragmentation is an effective DoS. As far as increasing the MTU size on your LAN links, you need to exercise a lot of care when so doing. I personally have never tried to change the MTU size on an Ethernet segment of any type (Ethernet_II/1500 has worked admirably, and I'm unsure of the result if I tried it); on Token Ring, going up to 4096 has indeed been beneficial in the past when dealing with large database writes, etc. Of course, the protocol I was using at the time supported 4096-byte frame sizes on Token Ring. I thought the frame-size limits for Gigabit Ethernet were 64-1518/1522 bytes? And isn't that the limit on most host IP stacks for Ethernet media? Or am I off in left field, here? Finally, I would say that on any medium, <100% utilization in and of itself isn't grounds for fiddling with the MTU. There are lots of other things to look at, first. --------------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice -----Original Message----- From: Roeland Meyer (E-mail) [mailto:rmeyer@mhsc.com] Sent: Wednesday, June 14, 2000 9:07 AM To: Valdis.Kletnieks(a)vt.edu; 'Marc Slemko' Cc: nanog(a)merit.edu Subject: RE: PMTU-D: remember, your load balancer is broken > Valdis.Kletnieks(a)vt.edu: Wednesday, June 14, 2000 8:07 AM > > On Tue, 13 Jun 2000 22:36:08 MDT, Marc Slemko said: > > It is also a concern that, in my experience, many of the links with > > MTUs <1500 are also the links with greater packet loss, etc. so > > you really don't want fragmentation on them. > > The worst part here is that I suspect that most of these > links (just on > sheer numbers of shipped product) are the aformentioned Win98 576-MTU. I just set my dial PPP ports to MTU=512+40=552, is this wrong? Where does the MTU=576 number come from? > I seem to remember that the *original* motivation for slow-start and > all that was Van Jacobson's observation that the most common cause of > a TCP retransmit was that an *entire* packet had been silently dropped > due to queueing congestion, and could thus be treated identical to > an ICMP Source Quench. > > Has this changed? Has "fragmentation" become a Great Evil, > rather than > an annoyance that some links have to deal with? I'm having some trouble getting full throughput from a GigE pipe. Even in the 100baseTX/FDX down-stream, I'm not getting full link utilization (everything on switches, Cat6509 and 3512XLs). I'm considering increasing MTU sizes to MTU=4096+40, or even larger. Most of the data transmissions fall into the 5KB-50KB range. The site can be considered a large portal. What would be the effect on my upstream? Would it create problems? The only systems that see the Internet are the web-servers (dual NICs).

6 5

MAE-EAST Moving? from Tysons corner to reston VA.
by Vinny India 15 Jun '00

15 Jun '00

Has anyone else heard this?

20 27

in-addr.arpa?
by Hank Nussbacher 15 Jun '00

15 Jun '00

Why would 216.136.44.104 do something like this? 10 sl-inetconn-1-0-0-T3.sprintlink.net (144.228.207.46) [AS 1239] 200 msec 204 msec 208 msec 11 pa1-atm0-6-bbr01.alby.twtelecom.net (207.250.101.2) [AS 4323] 244 msec 264 m sec 248 msec 12 pa1-atm0-5-acr01.alby.twtelecom.net (216.136.44.242) [AS 4323] 256 msec 252 msec 252 msec 13 learnl-ppp-1130-09-u242.alby.twtelecom.net (207.250.24.30) [AS 3857] 256 mse c 260 msec 256 msec 14 ip104.44.136.216.in-addr.arpa (216.136.44.104) [AS 4323] 404 msec 400 msec 3 80 msec -Hank

5 4