Re: KVM over IP suggestions?
Things you must pay attention to: (1) IP KVM should not use client software - good switches uses VNC and can work via WEB. The same with authentication. (2) If you connect IP KVM to normal KVM, check if they are well compatible in suich things as: - monitor recognition on KVM; - switching ports on KVM; (3) If you use multiple servers, check that IP KVM can keep all your screen resolutions and frequences. I saw a case when everything worked, but IP KVM could not recognize still screen and generated huge traffic all the time. The same with frequencees - we have one Compaq KVM which refuse to work with IP KVM. (4) Pay attention to mouse syncronisation. It is tricky and bad IP KVM can require turning mouse acceleration off. Good IP KVM should know mouse acceleration rules in Windows and Linuxes. (5) If you can use embedded IP KVM card such as DELL : DRAC-IV or Compaq - RIB card, use them - IP KVM do not provides server reboot function and rarely can provide virtual CD or virtual floppy. We use IP KVM (do nopt remember vendor; cheap one, price was about $600) connected to 3 16 port KVMs (chained together), and it is good add-on to other tools. But it do not replace normal console in all cases - mouse sncronisation, slow refresh makes long work on it annoying. DRAC-IV card , on other hand, replaces consokle in 95% cases (5% rely to _DRAC-IV crashh; DRAC-IV lost keybvoard; etc cases). For the new project, I'd better take everything from one brand vendor (even if they OEM this things in most cases), just to be sure that KVM's are compatible. For cheap project, there are many cheap IP KVM's on the market, but TEST IT IN YOUR ENVIRONMENT! - Original Message - From: Eric A. Hall [EMAIL PROTECTED] To: Drew Weaver [EMAIL PROTECTED] Cc: nanog@merit.edu Sent: Monday, August 22, 2005 9:56 AM Subject: Re: KVM over IP suggestions? On 8/22/2005 11:15 AM, Drew Weaver wrote: Howdy, I'm looking for a way to give our remote users access to their servers, perhaps a KVM-IP solution. Any suggestions would be helpful. http://www.nwc.com/shared/article/printFullArticle.jhtml?articleID=168500010 -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: KVM over IP suggestions?
DELL's DRAC-III is waste of money. DELL's DRAC-IV is a very good thing, and I find it replacing al consoles around (it have embedded monitoring with e-mail and SNMP alerts; have VNC based console servcie with perfect /not ideal, through/ mouse syncronisation, haVE VIRTUAL cd (SLOW, BUT WORKING) AND VIRTUAL FLOPPY, EASY-TO-USE INTERFACE (except strange password management), and so on. Compaq's RIB cards was good but expensive and nbot very reliable. Serial console can be fine, but do not eliminate normal console in many cases. - Original Message - From: Kevin [EMAIL PROTECTED] To: nanog@merit.edu Sent: Monday, August 22, 2005 1:26 PM Subject: Re: KVM over IP suggestions? On 8/22/05, Matthew Black [EMAIL PROTECTED] wrote: On Mon, 22 Aug 2005 11:15:23 -0400 Drew Weaver [EMAIL PROTECTED] wrote: Howdy, I'm looking for a way to give our remote users access to their servers, perhaps a KVM-IP solution. What we need is support for multiple users (more than 2), with access control that limits what users can connect to what ports on the KVM switch, and would allow you BIOS level access and os-installation type control over the server, would also be nice if it worked with windows and linux/unix based systems. Where possible, I strongly prefer to work with serial console on a hardware platform with firmware serial console support. This works for any OS that supports a command line, including Windows Server 2003. Dell includes serial console support in the BIOS on servers, and offers an enhanced remote management card which appears to work as a KVM-IP solution for Windows and (some versions of) Linux. I've never tried their DRAC/ERAC, only the serial console BIOS. All of the commercial remote serial console products we've considered so far have had serious security and/or usability flaws. This includes Cisco, Lantronix, Raritan, Digi, etc. We have a non-IP switch from Raritan and saw presentations on their IP KVM products. Seemed pretty impressive. One problem you may want to focus on is screen resolution since the video output must be converted to IP packets with a lower refresh rate. We're planning to buy a few of these switches for remote monitoring. The IP Reach video compression is bearable for installation and recovery. Video quality is degraded, but unless you really cannot stand moire patterns, it'll take an hour or so staring at the display before your headache becomes unbearable. I have experience with Raritan's Paragon IP Reach products, and they do work, but are expensive for such a low port density. Also it has been very difficult to work with tech support to make the Paragon product with a RADIUS server for OTP access control. The newer Dominion line may be better; I've heard some complaints about their serial console products, nothing either way about KVM. Kevin Kadow
RE: KVM over IP suggestions?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Sent: Monday, August 22, 2005 10:27 PM To: nanog@merit.edu Subject: Re: KVM over IP suggestions? We have a non-IP switch from Raritan and saw presentations on their IP KVM products. Seemed pretty impressive. One problem you may want to focus on is screen resolution since the video output must be converted to IP packets with a lower refresh rate. We're planning to buy a few of these switches for remote monitoring. The IP Reach video compression is bearable for installation and recovery. Video quality is degraded, but unless you really cannot stand moire patterns, it'll take an hour or so staring at the display before your headache becomes unbearable. I have experience with Raritan's Paragon IP Reach products, and they do work, but are expensive for such a low port density. Also it has been very difficult to work with tech support to make the Paragon product with a RADIUS server for OTP access control. The newer Dominion line may be better; I've heard some complaints about their serial console products, nothing either way about KVM. We've tested Raritan's integrated KVM over IP + serial products for a while, but were less than impressed with their interface tools. Both the standalone client and the ActiveX client were prone to crashing, sometimes taking the raritan device with it. We've since junked the servers for which we needed the KVM over IP for in favor of HPs with advanced ilo or IBMs with remote supervisor cards, if which I'd recommend HPs offering any day. // nick
BGP AS Sets in the wild
Hi, I was looking at route-views.routeviews.org for the BGP routes and i dont see any AS-Sets whatsoever. Are BGP routes with AS-SETs not generally leaked into the wild? Is this the case? I am under the impression that AS_SETs are generated whenever there are some routes that are aggregated. Is there any other way also to generate AS_SETs in BGP? Any clues. Thanks, Abhishek -- Class of 2004 Institute of Technology, BHU Varanasi, India
Re: 4-Byte AS Number soon to come?
On Tue, Aug 23, 2005 at 12:53:45PM +0200, Iljitsch van Beijnum wrote: On 23-aug-2005, at 11:53, Paul Jakma wrote: The IDR draft is awaiting implementation report. If this is true, it's very distressing. Drafts are deleted after about six months. That means that any implementations will be based on a no longer existing specification. That's wrong in so many ways. ... working code... based on the draft that is there, there are serious implementation problems, e.g. the draft needs clarification. one does not expect prototype implementations based on drafts to be production level code... well this one does not anyway. implement away. Is it common or uncommon to fire up 'ethereal' or 'tcpdump' to debug a BGP problem? I think I only felt the need to do this a handful of times over the last decade, but it's generally difficult to position tcpdump such that it will intercept the eBGP traffic. (It's easier if tcpdump is implemented on your router, of course.) i did during the BGP3-BGP4 transition, and a couple of times in the add-thousands-of-knobs to BGP4... I expect this transtion will be similar. --bill
Re: 4-Byte AS Number soon to come?
On Tue, 23 Aug 2005, Iljitsch van Beijnum wrote: If this is true, it's very distressing. Drafts are deleted after about six months. That means that any implementations will be based on a no longer existing specification. That's wrong in so many ways. Well, maybe that was a misunderstanding of IETF process of mine. But AIUI, it's intended to progress towards proposed standard, and getting implementations is part of that, in some fashion. The draft has been kept active by the IDR since 2001 btw. I think I only felt the need to do this a handful of times over the last decade, but it's generally difficult to position tcpdump such that it will intercept the eBGP traffic. Ok. So that's a not important then. I'm interested in operational use of any kind of passive BGP 'reader' btw - not just ethereal/tcpdump. (Just to make it obvious ;) ). regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: The doctrine of human equality reposes on this: that there is no man really clever who has not found that he is stupid. -- Gilbert K. Chesterson
Re: 4-Byte AS Number soon to come?
On 23-aug-2005, at 11:53, Paul Jakma wrote: The IDR draft is awaiting implementation report. If this is true, it's very distressing. Drafts are deleted after about six months. That means that any implementations will be based on a no longer existing specification. That's wrong in so many ways. Is it common or uncommon to fire up 'ethereal' or 'tcpdump' to debug a BGP problem? I think I only felt the need to do this a handful of times over the last decade, but it's generally difficult to position tcpdump such that it will intercept the eBGP traffic. (It's easier if tcpdump is implemented on your router, of course.)
Re: 4-Byte AS Number soon to come?
Paul Jakma wrote: On Tue, 23 Aug 2005, Iljitsch van Beijnum wrote: I think I only felt the need to do this a handful of times over the last decade, but it's generally difficult to position tcpdump such that it will intercept the eBGP traffic. Ok. So that's a not important then. I'm interested in operational use of any kind of passive BGP 'reader' btw - not just ethereal/tcpdump. (Just to make it obvious ;) ). IMO it is very important to have the ability to listen into a BGP stream at any point in time and have the reader decode the updates/ withdrawls starting from the next message boundary. -- Andre
Re: BGP AS Sets in the wild
On 23-aug-2005, at 12:36, Abhishek Verma wrote: I was looking at route-views.routeviews.org for the BGP routes and i dont see any AS-Sets whatsoever. Are BGP routes with AS-SETs not generally leaked into the wild? Is this the case? I guess they aren't. I am under the impression that AS_SETs are generated whenever there are some routes that are aggregated. Yes, but aggregation in the BGP protocol is a relic from the BGP3-to- BGP4 transition, AFAIK it's rarely used these days.
Re: Question about propagation and queuing delays
On 22-aug-2005, at 17:14, David Hagel wrote: This is interesting. This may sound like a naive question. But if queuing delays are so insignificant in comparison to other fixed delay components then what does it say about the usefulness of all the extensive techniques for queue management and congestion control (including TCP congestion control, RED and so forth) in the context of today's backbone networks? The answer is that delay is only one aspect of performance, another important one is packet loss. As link bandwidth increases, queuing delays decrease proportionally. So if you're using your 10 Mbps link with average 500 byte packets at 98% capacity, you'll generally have a 49-packet queue. (queue = utilization / (1 - utilization)) Our 500 byte packets are transmitted at 0.4 ms intervals, so that makes for a 19.6 ms queuing delay. So now we increase our link speed to 100 Mbps, but for some strange reason this link is also used at 98%. So the average queue size is still 49 packets, but it now only takes 0.04 ms to transmit one packet, so the queuing delay is only 1.96 ms on average. As you can see, as bandwidth increases, queuing delays become irrelevant. To achieve even 1 ms queuing delay (that's only 120 miles extra fiber) at 10 Gbps you need an average queue size of 833 even with 1500-byte packets. For this, you need a link utilization of almost 99.9%. However, due to IP's bursty nature the queue size is quite variable. If there is enough buffer space to accommodate whatever queue size that may be required due to bursts, this means you get a lot of jitter. (And, at 10 Gbps, expensive routers, because this memory needs to be FAST.) On the other hand, if the buffer space fills up but packets keep coming in faster than they can be transmitted, packets will have to be dropped. As explained by others, this leads to undesired behavior such as TCP congestion synchronization when packets from different sessions are dropped and poor TCP performance when several packets from the same session are dropped. So it's important to avoid these tail drops, hence the need for creative queuing techniques. However, at high speeds you really don't want to think about this too much. In most cases, your best bet is RED (random early detect/drop) which gradually drops more and more packets as the queue fills up (important: you need to have enough buffer space or you still get excessive tail drops!) so TCP sessions are throttled back gradually rather than traumatically. Also, the most aggressive TCP sessions are the most likely to see dropped packets. With weighted RED some traffic gets a free pass up to a point, so that's nice if you need QoS guarantees. (W)RED is great because it's not computationally expensive and only needs some enqueuing logic but no dequeuing logic.
LAN to LAN dial solution
Can anyone suggest, other than using Cisco's a brand of UK-compliant boxes that effectively will perform a PSTN dial up function, so that when the two boxes are connected, the LAN's are effectively bridged together Basically what we want to be able to do is connect a PC on a LAN, so that at will, a number can be dialed and you can then telnet to the far end Thanks Simon
RE: 4-Byte AS Number soon to come?
Is it common or uncommon to fire up 'ethereal' or 'tcpdump' to debug a BGP problem? I have done that a few times in my life (not that i have lived long enough like others in this list) Would it be problematic to have to either a) clear sessions for your analyser to fully understand the BGP stream or b) tell your analyser Are you're talking about clearing the BGP session between the two remote ends, for the *analyser* to work? This is weird and will most definitely not be accepted. There could be numerous such applications running that would want to look at the BGP stream. The peers are not expected to reset the session to make them work! whether the flow uses 2 or 4 byte ASNs? This would imply prior knowledge about the ASNs which may not be available with the analyser. Essentially, this draft as it stands is going to make it difficult to observe and comprehend BGP AS_PATH without either human intervention or restart of the session(s) concerned. A guage how much of a problem this would be in real-life (if any problem at all?) would be useful in determining whether it's worth lobbying to change the draft. If there isnt a wide installed base for the draft, and if there are solutions available that can solve this problem then i would prefer going ahead with the new solution and picking it up if it works! Kent
Re: 4-Byte AS Number soon to come?
On 23-aug-2005, at 15:16, Paul Jakma wrote: then i would prefer going ahead with the new solution and picking it up if it works! Well, in order to justify the hassle of invalidating existing implementations of the draft as it stands, I suspect there'd need to be sufficient examples of real-world problems with passive BGP 'readers' to get consensus in IDR to change. This is exactly why people shouldn't implement drafts except possibly as a private in-house feasibility study. There has been a huge inflation of the status of various IETF documents, to the degree than BGP today apparently isn't considered mature enough to be an internet standard. BTW, I find the notion that there is a new attribute that carries 32- bit AS numbers while at the same time the original AS path can either hold 16-bit or 32-bit AS numbers depending on the capabilities of the peer rather strange. Why not simply keep the current AS path 16 bits and create a new 32-bit one? And what's with that octet thing, anyway.
Re: BGP AS Sets in the wild
On 8/23/05, Iljitsch van Beijnum [EMAIL PROTECTED] wrote:
On 23-aug-2005, at 12:36, Abhishek Verma wrote:
I was looking at route-views.routeviews.org for the BGP routes and i
dont see any AS-Sets whatsoever. Are BGP routes with AS-SETs not
generally leaked into the wild?
Is this the case?
I guess they aren't.
I am under the impression that AS_SETs are generated whenever there
are some routes that are aggregated.
Yes, but aggregation in the BGP protocol is a relic from the BGP3-to-
BGP4 transition, AFAIK it's rarely used these days.
Sure there are...
route-views.oregon-ix.netsho ip bgp 24.223.128.0/17
BGP routing table entry for 24.223.128.0/17, version 1030251
Paths: (47 available, best #20, table Default-IP-Routing-Table)
Not advertised to any peer
2914 1668 10796 {11060,12262}, (aggregated by 10796 24.95.80.203)
129.250.0.11 from 129.250.0.11 (129.250.0.88)
Origin IGP, metric 1, localpref 100, valid, external, atomic-aggregate
Community: 2914:420 2914:2000 2914:3000 65504:1668
11608 2914 1668 10796 {11060,12262}, (aggregated by 10796 24.95.80.203)
207.246.129.6 from 207.246.129.6 (207.246.155.208)
Origin IGP, localpref 100, valid, external, atomic-aggregate
Community: 2914:420 2914:2000 2914:3000 11608:801 11608:1004
11608:5501 65504:1668
6079 1668 10796 {11060,12262}, (aggregated by 10796 24.95.80.203)
207.172.6.162 from 207.172.6.162 (207.172.6.162)
Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate
11608 3491 1668 10796 {11060,12262}, (aggregated by 10796 24.95.80.203)
207.246.129.14 from 207.246.129.14 (207.246.129.14)
Origin IGP, localpref 100, valid, external, atomic-aggregate
Community: 11608:1006 11608:550
--chip
--
Just my $.02, your mileage may vary, batteries not included, etc
Re: 4-Byte AS Number soon to come?
Hi, On 23-aug-2005, at 11:53, Paul Jakma wrote: The IDR draft is awaiting implementation report. If this is true, it's very distressing. The IDR draft awaits an implementation report in order to advance the draft to Proposed Standard. What is so distressing about this ? Drafts are deleted after about six months. That means that any implementations will be based on a no longer existing specification. That's wrong in so many ways. Drafts are deleted after about six months *unless* the drafts are renewed (republished). The draft we are talking about is an *existing* specification (draft-ietf-idr-as4bytes-10.txt). Yakov.
Re: 4-Byte AS Number soon to come?
Bill, On Tue, Aug 23, 2005 at 12:53:45PM +0200, Iljitsch van Beijnum wrote: On 23-aug-2005, at 11:53, Paul Jakma wrote: The IDR draft is awaiting implementation report. If this is true, it's very distressing. Drafts are deleted after about six months. That means that any implementations will be based on a no longer existing specification. That's wrong in so many ways. ... working code... based on the draft that is there, there are serious implementation problems, e.g. the draft needs clarification. one does not expect prototype implementations based on drafts to be production level code... well this one does not anyway. implement away. If you think there are problems with the draft please send an e-mail to the IDR mailing list describing the problems. Yakov.
Re: 4-Byte AS Number soon to come?
Folks, On Tue, 23 Aug 2005, Iljitsch van Beijnum wrote: If this is true, it's very distressing. Drafts are deleted after about six months. That means that any implementations will be based on a no longer existing specification. That's wrong in so many ways. Well, maybe that was a misunderstanding of IETF process of mine. But AIUI, it's intended to progress towards proposed standard, and getting implementations is part of that, in some fashion. The draft has been kept active by the IDR since 2001 btw. I think I only felt the need to do this a handful of times over the last decade, but it's generally difficult to position tcpdump such that it will intercept the eBGP traffic. Ok. So that's a not important then. I'm interested in operational use of any kind of passive BGP 'reader' btw - not just ethereal/tcpdump. (Just to make it obvious ;) ). May I suggest that you send your opinion on this topic to the IDR mailing list (idr@ietf.org), as it would help the IDR WG to reach a (rough) consensus on how to proceed with the draft. Yakov.
Re: KVM over IP Suggestions?
At 12:41 PM 8/22/2005, Aaron Glenn wrote: On 8/22/05, Simon Hamilton-Wilkes [EMAIL PROTECTED] wrote: They support P/S2 / USB / Sun and serial - though are a very expensive way to do serial. And (last time I looked, at least) they required an expensive, proprietary, Windows-only authentication server (DSView) in addition to the client software licenses and hardware costs. Avocent makes several products in the KVM/IP space. Not all of them are tied to Windows Server authentication. At the low end, they've got a sub-$1000 single port box that works nicely for front-ending existing KVM switches that have on-screen controls. We've used and tested 4 or 5 products in this single port space. Results have been fair, bad and ugly. I would not consider any of them to be acceptable or better. There are several issues. As someone else noted, these usually push a viewer to you over either Java or Active-X. The little Avocent uses Active-X, so I have to remember to load up IE before accessing it. Internal authentication is, in my experience, essential. After all, if you're connecting in to deal with the server that's doing your authentication, you're screwed, yes, there are likely expensive ways to avoid that situation. Serial redirection and terminal servers are an option, but only if all of your servers support that. VNC isn't an option, unless you like your terminal sessions going over unencrypted pipes or set everything up to tunnel over SSH or VPN. Solutions that use VNC direct to the target server are insufficient. If you can't talk to the BIOS of a server that's not feeling well, what's the point? Once a server is actually up, SSH into the server gets you all you need, or VNC over SSH if you must do some graphics. Mouse control: all of the KVM/IP products we've tested have had serious issues with mouse control. With Windows boxes, we generally do our best to get boxes far enough up to use RDP, and switch to that because it's much cleaner. With Linux machines we find this less of an issue as we don't run consoles in graphics mode, thus bypassing the mouse sync issue. For the original poster, if you want to have the ability to let customers at the console of their server, but not others, you're going to be stuck using expensive equipment, with the ability to handle multiple simultaneous users, or go with servers that have KVM/IP as an on-board option (Intel's is the one I'm personally familiar with. Someone else mentioned Dell has such too). We made the move to KVM/IP and APC power cycling/control equipment a few years back and have never regretted doing so. Dan
Re: 4-Byte AS Number soon to come?
On 23-aug-2005, at 16:16, Yakov Rekhter wrote: The IDR draft is awaiting implementation report. If this is true, it's very distressing. The IDR draft awaits an implementation report in order to advance the draft to Proposed Standard. What is so distressing about this ? A draft is work in progress. We don't even get to refer to it because it's deleted after 6 months. As such, it's hardly less ephemeral than a conversation. You can't build implementations based on that. But I guess this is what happens with the convoluted standards track mechanism that the IETF currently uses. One thing that bothers me very much about this is that it will make changes that happen in IETF last call much harder. Essentially that means that anyone who isn't in IDR doesn't get to have his or her input considered.
Re: LAN to LAN dial solution
[EMAIL PROTECTED] wrote: Can anyone suggest, other than using Cisco's a brand of UK-compliant boxes that effectively will perform a PSTN dial up function, so that when the two boxes are connected, the LAN's are effectively bridged together Basically what we want to be able to do is connect a PC on a LAN, so that at will, a number can be dialed and you can then telnet to the far end You may be asking something else, but pretty much every PPP implementation I've ever seen on a UNIX-like system or router has dial on demand capabilities. However, I do wonder if you are trying to express something unusual about this setup by the use of the term bridged as opposed to normal layer-3 routing. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
ISP's In Uproar Over Verizon-MCI Merger
Dan Neel writes in CRN.com: [snip] The California ISP Association (CISPA) claims the merger of Verizon Communications and MCI will threaten ISP business models. CISPA represents more than 180 ISPs. Mike Jackman, executive director of the Sacramento, Calif.-based organization, said the multibillion-dollar Verizon-MCI merger, announced in February, will run many pure-play ISPs out of business or force them to diversify their offerings--possibly into more value-added services that could compete with those provided by VARs and system integrators. Verizon and MCI expect to close their merger by the end of the year. Another blockbuster telecommunications merger--between SBC Communications and ATT--also is slated to close by the end of this year or in early 2006. Spurring the CISPA complaint is an Aug. 5 Federal Communications Commission decision to reclassify DSL service as an information service instead of a telecom service, which Jackman said frees phone companies like Verizon from regulations requiring them to share bandwidth with ISPs. The FCC has placed a one-year grace period on enforcement of the change, he added. [snip] http://www.crn.com/sections/breakingnews/breakingnews.jhtml;jsessionid=P4TBQHJM0MMKYQSNDBESKHA?articleId=169600170 Sorry for the long URL. - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: ISP's In Uproar Over Verizon-MCI Merger
I think that big carriers have successfully convinced regulators that the telecom deregulation in late nineties was bad for the industry. It certainly destroyed quite a few big companies, e.g. MCI and ATT. Also it dragged down a few big companies, e.g. Verizon has $40B debt. In the meantime, US is trailing other industrial countries in broadband penetration because no carrier is interested in investing and building an infrastructure to be shared by their competitors. The only way they argue to get the industry out is to have a few large companies with little competition. True or not, FCC is listening to them. On 8/23/05, Fergie (Paul Ferguson) [EMAIL PROTECTED] wrote: Dan Neel writes in CRN.com: [snip] The California ISP Association (CISPA) claims the merger of Verizon Communications and MCI will threaten ISP business models. CISPA represents more than 180 ISPs. Mike Jackman, executive director of the Sacramento, Calif.-based organization, said the multibillion-dollar Verizon-MCI merger, announced in February, will run many pure-play ISPs out of business or force them to diversify their offerings--possibly into more value-added services that could compete with those provided by VARs and system integrators. Verizon and MCI expect to close their merger by the end of the year. Another blockbuster telecommunications merger--between SBC Communications and ATT--also is slated to close by the end of this year or in early 2006. Spurring the CISPA complaint is an Aug. 5 Federal Communications Commission decision to reclassify DSL service as an information service instead of a telecom service, which Jackman said frees phone companies like Verizon from regulations requiring them to share bandwidth with ISPs. The FCC has placed a one-year grace period on enforcement of the change, he added. [snip] http://www.crn.com/sections/breakingnews/breakingnews.jhtml;jsessionid=P4TBQHJM0MMKYQSNDBESKHA?articleId=169600170 Sorry for the long URL. - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: ISP's In Uproar Over Verizon-MCI Merger
Richard Z [EMAIL PROTECTED] I think that big carriers have successfully convinced regulators that the telecom deregulation in late nineties was bad for the industry. does not take much convincing in dc that what is good for big business is good for america these days. It certainly destroyed quite a few big companies, e.g. MCI and ATT. no. they did brilliant jobs of destroying themselves, in two very different ways. randy
Re: ISP's In Uproar Over Verizon-MCI Merger
On 23-aug-2005, at 23:24, Richard Z wrote: US is trailing other industrial countries in broadband penetration I'm not sure that's the case, AFAIK the US holds its own. because no carrier is interested in investing and building an infrastructure to be shared by their competitors. The only way they argue to get the industry out is to have a few large companies with little competition. So I guess the choice is between lots of broadband against monopoly prices or less broadband at lower prices? Now I didn't take all that much economy in school, but something there doesn't sound right...
Re: 4-Byte AS Number soon to come?
In message [EMAIL PROTECTED], Iljitsch van Beijn um writes: On 23-aug-2005, at 15:16, Paul Jakma wrote: then i would prefer going ahead with the new solution and picking it up if it works! Well, in order to justify the hassle of invalidating existing implementations of the draft as it stands, I suspect there'd need to be sufficient examples of real-world problems with passive BGP 'readers' to get consensus in IDR to change. This is exactly why people shouldn't implement drafts except possibly as a private in-house feasibility study. In general, you're right; however, BGP documents have a special status. Because of how crucial BGP is to the Internet's functioning, I-Ds won't progress to RFC status (at least as Proposed Standard) without two interoperating implementations. For everything else, you're right. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: 4-Byte AS Number soon to come?
On 23-aug-2005, at 23:55, Steven M. Bellovin wrote: This is exactly why people shouldn't implement drafts except possibly as a private in-house feasibility study. In general, you're right; however, BGP documents have a special status. Because of how crucial BGP is to the Internet's functioning, I-Ds won't progress to RFC status (at least as Proposed Standard) without two interoperating implementations. Ah, that makes sense. So how does that work for work on TCP (which is even more crucial than BGP)? You have to have interoperable implementations before writing the draft? (I knew the IETF had some trouble with its internal organization. I had no idea it was this bad.)
Re: ISP's In Uproar Over Verizon-MCI Merger
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yo Iljitsch! On Tue, 23 Aug 2005, Iljitsch van Beijnum wrote: So I guess the choice is between lots of broadband against monopoly prices or less broadband at lower prices? You forget the third choice the ATT taught us so well before the big breakup: Less broadband at higher prices. Just look at how hard it has been to get Qwest to fulfill their promises of more broadband outside of the cities in return for less state control over prices. RGDS GARY - --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDC6K38KZibdeR3qURApARAJwJsixdlFEUAqjHJpR1WUICiKqfhQCdHkT+ i+e5xHWTrMohVirRV6pTS9Q= =5c3p -END PGP SIGNATURE-
Re: ISP's In Uproar Over Verizon-MCI Merger
At 05:45 PM 8/23/2005, Iljitsch van Beijnum wrote: On 23-aug-2005, at 23:24, Richard Z wrote: US is trailing other industrial countries in broadband penetration I'm not sure that's the case, AFAIK the US holds its own. because no carrier is interested in investing and building an infrastructure to be shared by their competitors. The only way they argue to get the industry out is to have a few large companies with little competition. So I guess the choice is between lots of broadband against monopoly prices or less broadband at lower prices? Now I didn't take all that much economy in school, but something there doesn't sound right... Economics don't result in a good solution, no. I'm not opposed to local telco and cable companies being the only players, IFF there's a must serve rule, same as there is for local telco service. There are lots of towns that have no broadband, and no chance of ever getting it unless there's a must serve rule like there was for rural telephone service. So, if we're going to put Ma-bell back together, then let's do it right and make last-mile broadband a required service just like the telcos have to provide dialtone. Or, let's stop the farce and recognize we're living in the United Corporations of America. (exits soapbox, slaps self for off topic rant)
Re: ISP's In Uproar Over Verizon-MCI Merger
..and life is probably going to get a lot more interesting for service providers. All today, we have leaders in the field with completely opposite views of the word: U.S. Broadband Policy Exists -- And Works, Claims NTIA's Gallagher http://www.advancedippipeline.com/169600336 [and] Nortel chief: U.S. needs new broadband vision http://www.infoworld.com/article/05/08/23/HNnortelchief_1.html And just to make life more fun, it looks like there's an effort afoot to get VoIP consumers to pay (read: tax) into the USF: New taxes could slam Net phone users http://news.com.com/New+taxes+could+slam+Net+phone+users/2100-7352_3-5842237.html So, aren't you glad that life isn't boring? ;-) - ferg -- Gary E. Miller [EMAIL PROTECTED] wrote: You forget the third choice the ATT taught us so well before the big breakup: Less broadband at higher prices. Just look at how hard it has been to get Qwest to fulfill their promises of more broadband outside of the cities in return for less state control over prices. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: ISP's In Uproar Over Verizon-MCI Merger
US is trailing other industrial countries in broadband penetration I'm not sure that's the case, AFAIK the US holds its own. Graph at the bottom of the article. http://www.mbc-thebridge.com/viewbridge.cfm?instance_id=304
Re: ISP's In Uproar Over Verizon-MCI Merger
On 24-aug-2005, at 1:04, Michael Painter wrote: US is trailing other industrial countries in broadband penetration I'm not sure that's the case, AFAIK the US holds its own. Graph at the bottom of the article. http://www.mbc-thebridge.com/viewbridge.cfm?instance_id=304 No, the one you want is around the middle. US looks like just under 13% at #12, while 2-3 are around the 18% mark and 17-20 at around 8%. So this looks like a nice comfortable spot right in the middle. It's remarkable that US DSL penetration is unusually low, there is only one other country where this is below 5%, while many countries have very little cable.
Re: ISP's In Uproar Over Verizon-MCI Merger
On Tuesday 23 August 2005 17:52, Fergie (Paul Ferguson) wrote: And just to make life more fun, it looks like there's an effort afoot to get VoIP consumers to pay (read: tax) into the USF: New taxes could slam Net phone users http://news.com.com/New+taxes+could+slam+Net+phone+users/2100-7352_3-584223 7.html So, aren't you glad that life isn't boring? ;-) Well, if my reading of the FCC ruling is correct, in 270 days (from the date of the ruling) the ILEC's will not be paying any USF fees on broadband anymore, since cable does not have to pay, so they have already stated they are reviewing options for alternate funding. Gee, Why not VOIP. -- Larry Smith SysAd ECSIS.NET [EMAIL PROTECTED]
Re: 4-Byte AS Number soon to come?
In message [EMAIL PROTECTED], Iljitsch van Beijn um writes: On 23-aug-2005, at 23:55, Steven M. Bellovin wrote: This is exactly why people shouldn't implement drafts except possibly as a private in-house feasibility study. In general, you're right; however, BGP documents have a special status. Because of how crucial BGP is to the Internet's functioning, I-Ds won't progress to RFC status (at least as Proposed Standard) without two interoperating implementations. Ah, that makes sense. So how does that work for work on TCP (which is even more crucial than BGP)? You have to have interoperable implementations before writing the draft? No. TCP is end-to-end; a problem shows up on that connection. By contrast, a BGP issue can affect everyone else, since your peers see only what you advertise based on your policy and what you've learned from others. Put another way, your problems (or your implementation's problems) affect others. That's not true for TCP, with the exception of congestion control behavior. (I knew the IETF had some trouble with its internal organization. I had no idea it was this bad.) Some would say that it's a feature -- rely on running code. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: BGP AS Sets in the wild
On Aug 23, 2005, at 4:36 AM, Abhishek Verma wrote:
I was looking at route-views.routeviews.org for the BGP routes and i
dont see any AS-Sets whatsoever. Are BGP routes with AS-SETs not
generally leaked into the wild?
Is this the case?
Not quite, see below..
I am under the impression that AS_SETs are generated whenever there
are some routes that are aggregated. Is there any other way also to
generate AS_SETs in BGP?
Well, yes, but mostly via proxy aggregation type stuff, which isn't
real common these days (i.e., dynamic proxy aggregation on behalf
of downstream ASes).
Yep, quite a few (I was just looking at this a while back for something
else). As of a few hours ago, route-views had 45 unique prefixes that
contained AS_SET path attributes. Interestingly enough, ~60% of those
AS_SETs only contain a single AS -- hrmm. It's also interesting to see
some of these AS_SETs, albeit only a couple, contain private AS space,
I'm wondering if some naive implementations remote-private-as-type
knob is letting them slip by inside AS_SETs on egress.
[EMAIL PROTECTED] grep { oix-full-snapshot-latest.dat | wc -l
1717
[EMAIL PROTECTED] grep { oix-full-snapshot-latest.dat | grep \ | wc -l
45
[EMAIL PROTECTED] grep { oix-full-snapshot-latest.dat | grep ^...[0-9]
* 24.223.128.0/17 129.250.0.11 1 0 2914
1668 10796 {11060,12262} i
* 24.223.160.0/19 129.250.0.11 1 0 2914
1668 10796 {11060,12262} i
* 64.132.88.0/22 209.161.175.4 0 14608
4323 {33127} i
* 64.132.102.0/24 209.161.175.4 0 14608
4323 {32510} i
* 64.132.220.0/23 129.250.0.1117 0 2914
4323 {18664} i
* 65.17.160.0/19 129.250.0.11 1 0 2914
1668 10796 {11060,12262} i
* 65.189.0.0/16129.250.0.1117 0 2914
3356 10796 {11060,12262} i
* 65.205.32.0/24 129.250.0.1155 0 2914
10913 10913 26134 {30060} i
* 65.221.0.0/19129.250.0.11 0 0 2914 701
11486 {15297} i
* 65.254.96.0/19 129.250.0.11 0 0 2914
7911 2552 {25662,25887} ?
* 66.162.17.0/24 209.161.175.4 0 14608
4323 {29704,65102} i
* 66.163.160.0/19 129.250.0.11 7 0 2914
3561 26085 {14776} i
* 82.135.152.0/21 129.250.0.11 0 0 2914
1299 8764 8764 8764 {31006,34037} i
* 128.116.0.0 129.250.0.11 0 0 2914
7911 14041 {16519} i
* 129.19.0.0 129.250.0.11 0 0 2914
7911 14041 {12145,16519} i
* 129.165.192.0/18 134.55.200.1 0 293
10886 1701 {270,65200} ?
* 140.31.0.0 129.250.0.11 0 0 2914 701
668 {132,3381} i
* 140.32.0.0 129.250.0.11 0 0 2914 701
668 {22,5957,14077} ?
* 147.241.0.0 129.250.0.11 0 0 2914 701
668 {13} i
* 147.249.0.0 129.250.0.11 0 0 2914 701
7381 {3561,6419,12178} i
* 168.215.137.0/24 209.161.175.4 0 14608
4323 {29704} i
* 200.62.40.0/22 129.250.0.11 6 0 2914
5511 18747 {12180,23383,23520} i
* 200.85.0.0/20129.250.0.11 0 0 2914 701
26617 {17079} i
* 201.217.192.0/19 129.250.0.11 6 0 2914
5511 18747 {26596} i
* 202.30.88.0/23 129.250.0.11 5 0 2914
4766 3608 3608 3608 17832 {9494} i
* 202.224.128.0/18 129.250.0.11 258 0 2914
4688 4688 4688 {18071} i
* 206.169.96.0/22 129.250.0.1117 0 2914
4323 {11636} i
* 206.169.208.0/22 129.250.0.1117 0 2914
4323 {21593} i
* 207.19.96.0/21 129.250.0.11 0 0 2914 701
7381 {14455} i
* 207.133.7.0 129.250.0.11 0 0 2914 209
721 27064 6026 {65535} i
* 207.235.48.0/20 209.161.175.4 0 14608
4323 {32258,32418,32434} i
* 207.250.94.0/23 209.161.175.4 0 14608
4323 {33395} i
* 208.16.208.0/21 129.250.0.11 0 0 2914 701
7381 {14455} i
* 208.142.248.0/21 129.250.0.11 0 0 2914
4436 14390 {27481} ?
* 208.254.0.0/19 129.250.0.11 0 0 2914 701
11486 {12156} i
* 209.159.192.0/18 129.250.0.1147 0 2914
30167 20412 {14507} i
* 209.213.209.0129.250.0.11 0 0 2914
7911 6517 {21953} i
* 209.234.168.0/22 209.161.175.4 0 14608
4323 {5710} i
* 210.23.192.0/19 129.250.0.11 4 0 2914
9299 9299 7491 {23862} i
* 210.23.208.0/21 207.246.129.6 0 11608
2914 6453 7491 {23862} i
* 210.23.208.0/20 207.246.129.6 0 11608
2914 6453 7491
RE: 4-Byte AS Number soon to come?
This is the first of many steps. And to be fair to the authors, the process got held up due to the base draft being re-written. So, the key discussion points are (as Yakov has indicated as well): a) Are there any technical problems with the specification b) Does the specification cause operational problems? c) General concerns about the design of the additions to BGP (scaling, etc). Implementation reports give us the opinion of those who have already implemented the protocol. That's usually worth hearing about. Sue -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Iljitsch van Beijnum Sent: Tuesday, August 23, 2005 10:31 AM To: Yakov Rekhter Cc: NANOG list Subject: Re: 4-Byte AS Number soon to come? On 23-aug-2005, at 16:16, Yakov Rekhter wrote: The IDR draft is awaiting implementation report. If this is true, it's very distressing. The IDR draft awaits an implementation report in order to advance the draft to Proposed Standard. What is so distressing about this ? A draft is work in progress. We don't even get to refer to it because it's deleted after 6 months. As such, it's hardly less ephemeral than a conversation. You can't build implementations based on that. But I guess this is what happens with the convoluted standards track mechanism that the IETF currently uses. One thing that bothers me very much about this is that it will make changes that happen in IETF last call much harder. Essentially that means that anyone who isn't in IDR doesn't get to have his or her input considered.
